Danny Bloemendaal wrote:

On 13 dec 2007, at 08:41, Raphael Ritz wrote:

Tom Lazar wrote:
On 11.12.2007, at 13:35, Laurence Rowe wrote:

I'd like to see the following for 3.1:

#210: Improve UI support for objects on multiple workflows

DCWorkflow allows for a chain of workflows to be specified for a type.

please explain. does chaining mean, that an object/type can have multiple workflows associated sequentially? or does each given state have the sum of all of the workflows transitions available?

More the latter than the former.
Objects can be subject to several workflows at once.
This implies multiple state variables of course.
Indeed you get a sum of all possible transitions offered.

I used to use this feature to provide locking functionality
before Plone itself did it (but in a different way now).
If you want to see an example in action check out my
LockingWorkflow product in a Plone 2.5 site.

And to drive home the point here: the CMF workflow tool
and DCWorkflow have supported this from the onset.
It is only Plone's UI that's kind of hiding this from you.

and BTW: +1 from me on the issue

I truely think that this isn't as trivial as it may seem. Is it only a UI issue? I know plone relies on several locations for the review_state attribute. What if an object has several states (which is possible if you have multiple workflows assigned)? Aren't there configlets that allow you to do things with this attribute like the navtree? What about worklists? I think that when we agree that an object can have more than one states, we have to support it everywhere in a concise way. I want to see a list of all the locations and situations where this may be an issue. Is the code truely multiple-state/transition aware? It's not only changing content_status_modify in my opinion. The state change drop-down should also show that there are more workflows and perhaps group the transitions per-state.

So, my point is: we either do it right or we don't do it at all :) And for now: +0

Danny.


We already do it, just not very well ;-) In 3.0 it works so long as you keep your transition ids unique across workflows. Catalogued workflow variables are calculated so that the first in the chain takes precedence, so nothing breaks here.

Are worklists still used in Plone? They are a per workflow feature of DCWorkflow anyway, so are not affected.

Workflow actions are already grouped as the actions are calculated sequentially from workflows. It would be nice to have a separator and a workflow title shown too, but I'm not sure what this should look like UI wise. How about this?

-----------
Workflow 1
Submit
Approve
-----------
Workflow 2
Confirm
Reject
-----------
Advanced...


Laurence


_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to