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

[Tres Seaver]

Jim Hebert wrote:
 
> 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)

Nope;  the beta this week *will* start a feature freeze, however.

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

Hold that thought. :)

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

Heh, you'll fall off the wagon;  ZPT is not reeely aimed at folks
who could figure out how to do "horrible, sick things in DTML".

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

We hadn't initially planned for them to be demo'ing CMF at LWE:
it so happened that the planets aligned, Shane and I made a bunch
of astonishingly-compatible checkins, Ken figured out how to
slurp in tens of thousands of mail messages, all at the same
time.  So we went with a CMF-based demo, but without giving the
booth staff enough time to prepare for much more than the
scripted demo and their general Zope knowledge.

> Now I've installed the final 1.0alpha and believe the answer is
> no, from my use of it.

We *expect* people to replace different policies for their site;
in fact, we expect to make a lot of our margin on consulting
projects leveraging the 80% or so of the CMF which matches the
customer's needs, customizing the other 20% or so (WAG numbers,
I'm sure).  

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

One customization might work something like:

 0. Author submits document, living in her "My Stuff" folder,
    for review.

 1. Reviewer approves submitted document, selecting its
    "permanent" location within the site (the tool might help
    with this).

 2. Workflow tool changes the document's state, moves it
    to its new home, and *removes the author's edit privileges*,
    leaving the document editable only by more trusted members.

 3. Workflow tool leaves a "Favorite" (think, "symlink") in the
    member's folder, pointing to the new location.
 
> 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.

The short reply here is that this kind of policy is what we are
already using, with fair success, on zope.org;  yes, it leaves us
open to some abuse, but it hasn't caused any huge problem so far.  

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

I have not been happy with using versions for content, either
(they don't yet play nice with the catalog, for instance).  I
*have* had considerable success using them to tweak both
presentation and through- the-web logic in a safe way.

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

"Mergeable versions" is a hard problem;  I wouldn't expect to see
them in the near future.

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

I don't honestly think so;  I expect that replacing the workflow
tool with one which implemented your policies would be a far
easier task than teaching (and trusting) content-oriented people
to use the ZMI.

> Am I preaching to the choir, ie, is workflow already planned to
> be extended to edits?

Not in the shipped workflow tool, at least not in the near
future.  We have some refactoring planned during the beta, to
remove the last vestiges of workflow knowledge from the content
objects themselves;  at that point, replacing the tool will be
even simpler than it is now (one might even be able to replace it
with a folder full of Python Scripts / External Methods!)

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

Thanks for the feedback!  I'll be working on a "customizing the
tools" document over the beta cycle, and will try to indicate
just how we envision that working as the way to tailor the CMF to
the needs of your site.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org