[Framework-Team] Re: Two more PLIPs

Laurence Rowe l at lrowe.co.uk
Thu Dec 13 11:51:29 UTC 2007


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





More information about the Framework-Team mailing list