[Zope-PTK] the workflow in the sample "Portal (new)"

[Shane Hathaway]

Jim Hebert wrote:
> Whew, all that said: Can someone explain to me in what scenario this
> workflow (the submitted/approved stuff) accomplishes its goal? I was at
> LWE and tried to get several different booth reps of DC's to tell me if
> the CMF demo that they were showing me allowed edits to existing portal
> documents to be subject to workflow just as new documents are, and no one
> seemed to know (no disrespect to them, they're some of the smartest and
> most helpful booth staff I've ever met!).  Now I've installed the final
> 1.0alpha and believe the answer is no, from my use of it.

This is excellent feedback, Jim.  At the moment the answer is no -- the
CMF workflow does not keep the user from making changes to the document
after it has been submitted.  A few lines in WorkflowTool.py could be
tweaked to allow this.  But we're doing a little redesign instead; read
on...

> When we deployed Zope at VistaSource, we really were searching for
> workflow, and finding nothing obvious, found Version objects being closest
> to it -- we could control who was allowed to "save" within a version, the
> existing revision of the doc would be public while the writer's new
> revision sat waiting to be committed, and the reviewers did the
> Version-saves. We ended up abandoning this solution as well because we
> couldn't tolerate the inability of Version objects to deal with any sort
> of merge, causing the entire / to lock up if someone added a new page
> while working in a Version.

I've been collecting bits of wisdom from community members, web sites,
and magazine articles about workflow.  I am convinced that Zope has
almost all of the right pieces in place to be a good workflow engine,
and I think we can narrow down exactly what it is that Zope *doesn't*
have yet.

      - It should be possible to vary the workflow associated with
        an object independently of the object's class.

      - Users' rights to manipulate an object should depend not only on
        the set of roles and permissions granted to them, but also
        on the workflow status of the object.

      - It should be possible to index objects based on their workflow
        status.  This would allow the creation of "workflow queues", or
        user task lists.

Once we had this list, I set about making these things possible in the
CMF.  Today I rewrote the portal_workflow interface and the WorkflowTool
implementation.  I also wrote a fishbowl-like proposal that I would link
to if it weren't for some odd new problems on cmf.zope.org.

> Now, someone in the DC booth at LWE told me that someday Version objects
> will get a merge capability and move away from the exclusive-locking
> semantics it has now. It's amazing to me to think that letting
> users loose on the "bare metal" zope management interface, and just
> teaching them to use versions (something we've done successfully already)
> might beat the CMF to being a workflow solution that we can use.
> 
> Am I preaching to the choir, ie, is workflow already planned to be
> extended to edits?

Yes.  With the new architecture, you'll have a lot more freedom to weave
workflow into class methods.  Hopefully we can get it out this week. 
I'll publish the link to the proposal once the cmf.zope.org problems are
sorted out.

> Thanks, and no offense intended to any of the developers, the product is
> simply amazing, I'm spoiled by how perfectly it's fit some of our needs, I
> guess. =)

The Zope community is simply amazing as well.  I am pleased with the
support we get.

Shane