I'm trying to change the WF for iterate. I want to prevent the person who modified the content from checking it back in and require it go through approval.
He's saying whats in the workflow.txt which describes how to have a different workflow for a working copy than during document creation. and I agree thats not what he's after.
I'm also interested in this. I would have thought if you have roles setup so contributors can't publish then it should also be the case that checkout permission is somehting a contributor can do but they can't check in, rather checkin is a permission given to a reviewer role. If thats not that the case then maybe you can make it the case by adjusting permissions? I don't think you actually want a different WF.
It does appear the permissions don't really make a lot of sense when combined with Plones default workflow.
You want to take away checkin and checkout from owner since default workflow doesn't allow an owner to edit a published document.
You want to give checkout to the "Contributor" if anyone that can create a new document can suggest edits to an existing one.
And you want to give checkout to the "Reviewer" and instruct them to use checkout instead of "publish" WF action (since checkin will replace the WF state with that of the published item during checking... would be nice if "publish" did an automatic checkin...".
Finally you might consider taking away the ability for Editors (and others) to edit a published item if you want to enforce checkout and review. To do this you need to modify the normal plone WF to ensure that the publish state removes the edit permission from the roles in that state.
I was trying to use the WF. since we use WF to manage the original creation of content and editing of existing content, I think a WF should be used to manage the editing of existing content.
My question was: why isn't this iterate WF registered as a WF and displayed in the list of WF in "portal/workflow"?
@rileydog I think you misunderstand iterate. It's not a WF. It would seem intuitive that it is but its not. Iterate has two actions that are not WF actions or states. Checkout which creates a copy and puts it into a "private" state and allows the objects WF to start again. And "checkin" which does a switch with the current state of the main item. ie its allowing two parallel WF to run at the same time. The permission changes I talked about help that process feel like its part of one workflow but its not. You can also see this in the checkin and checkout actions are under the "action" menu and not in the change state menu.
I appreciate your help to date and if my comments below go deeper than you want, I'll understand if you tap out. Also, it may be that Iterate isn't set up to work the way I would like or my ideas aren't useful.
I understand the above permission changes you propose. I assume this would hide the "check-in" except from those with certain roles. However, changing permissions isn’t the same as using the original WF:
In your post: “Checkout which creates a copy and puts it into a “private” state and allows the objects WF to start again”. But the WF doesn’t start for the copy as it doesn’t have a WF, it is simply check-in (Action) by the person who edited it.
When a person, with check-out permissions but withhout check-in permissions, finishs editing, how does the person responsible for reviewing and checking-in the revised content know the content is ready for review? With WF the person can receive an email, message, or the content displays in the review list.
WF is, potentially, a series of reviews. With simple permission to check-in, this isn’t possible.
Thus any changes to the content do not follow the same permissions WF as the original content.
Question:
The “copy of ...” is a new instance of same content type as the original (in the ZMI, I see both).
So, when the copy is ‘checked-in” why doesn’t the checked-in page be check-in as ‘draft’ and then use the same WF as the original content type? Thus the ‘checked-in page” would not replace the ‘original page’ until it goes through WF and replaces the ‘original’ page.
I'm putting together a quote at the moment for the same functionality so it's of benefit to understand how this works too. Note, I haven't tried my suggestions to date so YMMV.
My understanding is based on the documentation it might be wrong.
That’s because not all contributors have the Check in privilege. If that option is missing from your Actions menu:
Use the State menu.
Submit for publication.
Ask a reviewer to not change the state.
Ask the reviewer to perform the check in on your behalf instead.
The check in routine will handle the state.
From your comments you seem to be saying in your case that a checked out page doesn't have WF. The documention seems to say it does, but with the default set of permissions its not needed. Thats because the Owner is by default given both checkout and checkin permissions so regardless of the copies WF state they can just skip WF and checkin themselves. What you seem to want to do is prevent anyone from skipping the WF and only allow the reviewer to do the checkin as described above in the documentation. To do that you need to prevent checkin. Then the full usecase would be something like this
Contributor creates doc and submits if for review (WF transition)
Reviewer reviews then publishes doc
Contributor wants to suggest and edit and clicks "checkout" (not a WF transition)
Contributor makes changes then submits for review (WF transition on copy). checkin is not available.
Reviewer reviews copy and now clicks "checkin" and not "publish". This could be confusing so requires training.
I'm not sure but I suspect content rules should still work to send an email but need to test this. I suspect however the worklists portlet and collections won't work to show a list of items that need to be reviewed since the copy is sort of invisible. However a quick look at the code, I can't really see how this invisible thing is achieved other than just the fact that normally a copy is set to private and most people don't use WF on the copy, therefore private hides it from most collections. Someone with more indepth knowledge might have a better answer (such as @tomgross, @jensens, @mauritsvanrees or @pbauer), or you could just try and see
BTW, an idea that would make this process much nicer would be two new content rules actions for checkin and checkout. Then you could setup a workflow with a "Make suggestion/checkout" workflow transition that automatically does a checkout using a content rule. And you could setup a content rule that any publish transition on a copy results in an automatic "checkin". That would make the system more intuitive as checkin and checkout would become part of WF and the action to make something live is the same regardless if its a copy or baseline (ie publish tranistion).
You can see someone has already done part of this here - plone - HTTP redirect after check in event - Stack Overflow. It would be nice if this was in the core.
To me it seems that it is a bug that the default plone WF allows you to enforce review on content during creation but doesn't enforce review on working copies.
Plone has several workflows to choose from, or you can create your own. Which are you using?
It sounds to me like you have a very simple workflow that only has two states: private and published. Is that true? You would need one where you have a submit transition that puts the content in a pending state. Then reviewers can pick it up.
A couple of weeks ago, I removed the checkin permission for Owner, like Dylan suggests above, in a client project that has been heavily using Iterate for years.
@mauritsvanrees How do reviewers know to review on copy once the contributor has submitted for publication? Does the worklist portlet work as normal? Do content rules work on copies? Can you create collections that include both the baseline and the copy?
Would you support a change to the core so Owners can't checkin but Reviewers can and Contributors can checkout (but can't checkin)? That would make it inline with how plone normal workflow works.
For the review portlet a copy is the same as any other content. The only difference is that it has a relation or reference to the original, and maybe a marker interface. So as long as it is in the state 'pending', you will see it in the review list.
Yes, owners probably can do too much currently. I think their permissions have been reduced a bit at some point, maybe already in Plone 4, but they still have some extra permissions. Owners should not be able to check-in. I would support that change.
On top of that, it may make sense if installing Iterate would change some of the default permission settings in Plone, especially removing some permissions from Owner.
Also, it may be that Iterate isn't set up to work the way I would like or my ideas aren't useful.