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

[Jim Hebert]

Up front, I'll say that I acknowledge that a) this is an alpha of the
final product (and it's not clear to me if alpha implies feature-frozen or
not) b) That this is a demo use of the Framework, and that I completely
agree with the spirit of the "there is no perfect-for-everyone CMF, we
just want to provide you the chunks you slap together to make a
perfect-for-you CMF" messages I've seen coming from the developers.
What follows is intented to be constructive feedback from someone who is
at best a high end user of zope, but barely a developer for new things
within zope. (I'm one of those guys doing horrible, sick things in DTML
rather than learn python, I'll reform when Presentation Templates are
released I swear...)

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.

All of the use cases for this flows-through-revieweres stuff has to have,
as their common thread, some aspect where the writer might say or do
something, at some time, either accidentally or on purpose, that shouldn't
be said or done on the site, and if the writer isn't subject to workflow
on revisions that take place after the initial publication, I don't
understand how the site acheives the goal of protecting themselves from
accidents/malice on the part of the writers. (E.g., I as a writer get
something innocuous approved, and then during a revision I slip up and
mention The Company Secret, or libel someone, or whatever.)

About the only way I could see that working is if the document was yanked
from published back to pending every time a writer was going to work on it
-- however, that doesn't seem very feasible, since it causes the old
version of the document to disappear in the interim. And the fact is,
editing doesn't mandate it goes back to private first, so in the cae of
the malicious user, it's not an answer.

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.

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?

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. =)

jim