Hi @emodric @wizhippo!
I can understand that you are disappointed. Let me give more details about our conclusions.
When we started to work on this feature we wanted to do it like it was on eZ Publish (sending the item to the trash). We have a lot of requests to implement the same features exactly like they are on eZ Publish
When we asked you this question, it’s because we wanted to have your feedback and
unpublished status was not part of the available answers on the first poll (on Slack). You suggested this new status, we listened and we started to work on this option.
After several iterations (design, specs, meetings with the engineering), we thought that it might be too risky to introduce a new status before v2.5 LTS (it’s a shorter release due to the certification phase). Then, we realized that we already have an
archived status that can do the job. “Why not using it?”
We also discussed the naming and editor experience. From the user perspective having a button
Unarchive that matches the version status makes more sense.
The end result (frontend) will be the same: the content won’t be accessible. The visibility of locations won’t be changed, meaning that
Unarchiving a content item will restore the content like it was before. So there is not a big difference with
For more transparency with the community and because it was a change compared to what has been discussed here, I decided to share it with you before the spike that we will have during the next sprint.
Happy to keep discussing.
Details about the version status:
- archiving a content item will change the status of the published version to archived.
- unarchiving a content item will change the latest archived version to published
- when a content item is archived it won’t be possible to delete archived versions
- editing and publishing an archived version will create a new published version and the content item will be visible again
- Error will be displayed on the frontend when accessing sub-items of an archived parent.