[Zope-CMF] DCWorkFlow Guard Expressions?

[Doug Hellmann]

On Friday 25 October 2002 1:18 pm, Paul Winkler wrote:
> On Fri, Oct 25, 2002 at 10:53:14AM +0000, Florent Guillaume wrote:
> > An automatic transition is a transition that is automatically followed
> > after another transition, if it's allowed to (by its guard).
>
> (snip)
>
> > For your problem you don't need automatic transitions, simply complex
> > guard expressions (they can call python scripts).
>
> Hmmm, I don't understand how I would do that.
> Let me describe the situation, and maybe someone can
> suggest if/how this could be modelled in DCWorkflow
> or an alternative workflow. (I'm reading up on Openflow
> at the moment, just getting started.)
>
> I also describe below an alternative solution that's
> occurred to me.
>
> Here's what I need:
>
> Content team works on Document foo on local server A.
> When team is happy, they push foo to remote server B (using ZSyncer).
> They do not otherwise have access to server B.
> (that would inevitably lead to somebody editing live content, and
> we don't ever want that to happen.)
>
> This can be part of the Publish transition. No problem so far.
> Retract can be made to delete the remote voo via xml-rpc.
> Still no problem.
>
> The problem is that when content team further edits foo
> on local server A, the Document's state needs to
> be set to "Revised" which is entered anytime foo exists
> on A and B, but A is newer than B.  Thus they can tell
> at a glance what content is up to date on the production server
> and what is not.  Furthermore, if at any time foo goes away
> on B (e.g. some clumsy administrator accidentally deletes it from B),
> the state must be changed back to the inital state
> ("Private") so the content team can easily see that it's
> not on B.
>
> So it seems to me that my states depend on dynamic factors
> which are not part of the workflow.  They are simple
> questions to ask ("does http://B/foo exist?  is http://B/foo
> newer than http://A/foo?") but the problem is that they
> could conceivably change at any time. My states are not static. :-)
> I certainly don't want to go modifying every manage_beforeDelete
> etc. to make sure that it notifies the workflow, but I wonder
> if I might have to.

Maybe you just need more states.

When you move content to B, make it "Synced".  Then, to edit something that 
is "Synced" you would move it to another new state "Revising."  When you 
publish from that state, use another new state "Revised."  When Revised 
content is pushed to server B, it moves back to Synced.

With this workflow, both Published and Revised content in A is newer than 
what is in B.  Published content should not exist on B, and Revised content 
needs to be updated.

Doug