[Zope3-dev] Workflow Usecase

[Shane Hathaway]

Chris Withers wrote:
> I thought I'd throw this one out for you guys to think about.
> 
> I have some CMF content which I don't want the author to be able to delete when
> its in a certain workflow state. Of course, they need to be able to delete other
> stuff in the same folder.
> 
> I can see no way of doing this other than a hack in folder_delete to check if
> the user has the 'Delete objects' permission on the object itself, rather than
> just the folder.
> 
> It would be great if Zope 3 solved this in a nice graceful way :-)

I'm going to tell you the solution I've found that works quite 
well--even on Zope 2.  Paul, some of the sprinters in Brazil, and I were 
talking about this just a couple of days ago, and I don't think I 
expressed the idea adequately, so I'll try again.

First, you set up a version repository.  I don't know whether this is 
available at cvs.zope.org, but it works even though it doesn't have all 
the planned features.  Then you version all of your content (including 
scripts, templates, etc.)  You set up three checkouts, one for each of 
your stages (development, staged, and production).

You allow people to edit *only* in the development stage.  You give them 
controls that allow them to check in their content easily and stage it 
or put it in production.  The staging controls should be governed by 
workflow in some manner.  Staging content means updating the staging 
area to the same revision as what is in the development area; publishing 
content means updating both the staging area and the production area.

This solution has a lot of benefits:

1 - You can allow authors to change their content even after it has gone 
to production, because the new changes won't be reflected automatically.

2 - You can have any number of stages and you can set up any kind of 
workflow requirements.

3 - You have plenty of redundancy.  If an object breaks, you can just 
revert a revision or something.

4 - You can write the UI for your objects without needing any awareness 
of versioning or staging.  All this functionality can be "bolted on" 
without changes to your main code.

The only downside I can think of is that you end up with several copies 
of your objects, which takes up more HD space.  What are you going to do 
with your 100 GB drive anyway, though? ;-)

Shane