A customer would like that anything editors do is moderated by reviewers.
By default in Plone, if someone is editor, he/she can modify a published content, and the modification goes online directly.
My customer does not want to allow that.
I can fix it by turning the editor into contributor and by activating the Working Copy feature. Hence, the user can create a new draft copy, submit it to the reviewer, and the reviewer can validate the draft.
But what about deletion? We cannot submit a "draft deletion" (so reviewer could validate the deletion and it would delete the published document).
Is there anyway to do that?
Seems like a pretty good idea, if the transition is labeled something like "Request deletion", and content rules were in play.
There are paradigms for safety in deleting content:
Look before you leap: give only moderators or admins deletion permission and use workflow, content rules, and such to enforce.
Easier to ask (your admin) for forgiveness than permission: I have been using zc.beforestorage and ZEXP programmatically 3-4 times in the last two weeks to undelete stuff (I pack to days=7) at the request of my users and customers. I'm almost tempted to write an add-on that makes this user-facing (and not my job). If such a tool existed, the user would email the site content admin if they needed something back; the content admin could possibly get notification of the deletion automatically (via content rules), and only a user with "Site Administrator" or "Manager" roles should be able to un-delete in most cases (IMHO).
Yes, a workflow state sounds good, thanks @espenmn.
And as @seanupton said, a content rule to actually delete the content should work (I just need to check what happens if we have an intermediary screen regarding broken links).
@seanupton. I like the idea of building on beforestorage such that users can view a site at a certain date and either overwrite an object with an old version, or recreate an old version after deletion. This fufills a gap we are missing in terms of enterprise features.
It would only work up until it was last packed I guess but thats not so bad. But I think it might even be possible to somehow mount .old files such that you can browse history before the pack.
It could also be a less risky way to allow undo in the plone UI. Since zmi undo issues around not being able to tell which objects an undo will affect, and working out which users are allowed to undo.
We usually pack to 7 days, which is likely good enough 80% of the time.
I also keep bzip2 compressed FleStorage backups of my RelStorage main DB, but having to keep (or re-compute) the *.fs.index and unzip the backups could have some expense making it tricky to "time machine" into the backup files I keep beyond the pack limit. I think I might consider having my zodbconvert-based backup process use zc.zlibstorage wrapped FileStorage instead of bzip2 compressing my .fs files (plus keep the .fs.index files), if I was able to get easier access to use for an undelete feature.