[Zope-CMF] Understanding Folders and Workflow

[Erik Lange]

At 10:16 PM 10/4/02, Carl Rendell wrote:
>A few of us have been discussing Folders and Workflow, and I'd like to get 
>some closure on the subject.
>
>So far it appears that any folderish type which is governed by workflow 
>will, on its initial workflow state change (private to published) change 
>the allowedRolesAndUsers attribute for items within the folder's branch.
>
>This only occurs on the initial state transition though. Subciquent 
>retraction/rejection and publishing does not have the same effect.
>
>The questions are..
>
>Is this a bug, or by design?

That depends on the situation - it's all in the eye of the beholder :-)

>Should something be changed to make the behavior more consistent?

If changed, it should be optional IMHO.. or a "plug-in"-product ?  Then 
there could be several different "WF Folder" plug-ins for people to choose 
from...

>Are folders or folderish types _supposed_ to be controlled via workflow?

Not always..

>The environment is:
>
>Zope 2.5.1
>CMF 1.3
>
>I, and perhaps others, would really like to understand this more.

We've been banging our heads with this one quite a few times - there's not 
one right solution, as I see it.

The enviroment where we have the "problem" might explain why. We use a 
folderish object as a "media event", which contains a logical 
masterfile-object - compared to a physical videotape - in this folder the 
user also creates logical "clip" in the masterfile (timestamps for 
start-end of the clip in the masterfile).

Now, should the masterfile and the clips be published together with the 
media event ?

Not always. When we're making an online community where ordinary user can 
upload, edit and publish streaming media, they should - otherwise the 
ordinary user gets totally confused going through and endless proccess of 
publishing objects.

We've solved this in two ways:

1. A multiple publishing page, that lists all objects in a folder, where 
you can select by check-boxes,which objects (the event, the masterfile and 
the clips) the user wishes to publish (or retract, or hide, or make visible).

2. A script we call from a custom "publish"-button in the UI, that inwokes 
a workflow change on all products in an event-folder - this way the users 
don't have to think about (or know, even) that the different objects has to 
be workflow-processed - the user just click "make public",  and that's it.

Building solutions that are used in production enviroment by broadcasters 
and webcast facilities, is a whole different ball game... Here it's very 
often that an event never gets published, but the containing masterfile is 
"shared" (workflow state visible) between community members on a certain 
level, who then creates clips in the masterfile, and publishes or 
syndicates the clips out of the production community.

And then there's all the custom-solutions in between... so there's no easy 
answer here, but flexibility is the key :-)

Regards,
Erik