[Zope-CMF] Re: workflow bug

[Tres Seaver]

seb bacon wrote:

> * Tres Seaver <tseaver@zope.com> [011027 09:36]:
> 
>>seb bacon wrote:
>>
>>
>>>The use of
>>>
>>> content_creator = content.Creator()
>>>
>>>in DefaultWorkflow, assumes the object in question implements
>>>DublinCore, which is a bug IMO, since nowhere else does the Workflow
>>>assume anything about the object it's passed.  
>>>
> 
>>Hmmm, a couple of things:
>>
> 
>>- Workflowable items are assumed to be "content" within CMFDefault's
>>  DefaultWorkflow, and "content" is assumed to implement the DublinCore
>>  interface.  What objects are failing for you here?
> 
> I was playing with involving folders in workflows, without having them
> implement DublinCore.  The assumptions you list are reasonable
> assumptions, so I guess the implementation doesn't count as a bug.
> Instead, I'd say it was a bug that the assumptions aren't always
> obvious.  I suppose I was confusing CMFCore assumptions, which are
> codified in the interfaces, with CMFDefault assumptions, which are
> implicit.  How about making these explicit in the doc string of
> DefaultWorkflow? 


Sounds reasonable.

 
>> - I think your '_getCreator' function probably belongs in
>>   CMFDefault.DefaultWorkflow, rather than in CMFCore, as it encodes a
>>   knowledge of the default implementation of Creator which may not
>>   apply everywhere (e.g., we already know that mapping "executable
>>   ownership" onto Creator is inflexible, and often bogus, and might
>>   like to fix that.)
> 
> yep, but a moot point, considering:
> 
> 
>> - I just looked at how the workflow is using Creator, and it "smells
>>   bad":  Creator is used only to allow the "reject" action,
>>   if the user is owner;  this should really be a permission check,
>>   or at least a role check (for the 'Owner' local role, rather than
>>   for "executable ownership").
> 
> It's also used as a guard for the 'retract' transition.


Hmm, I think I mis-typed:  owners can't reject, but only retract.


>>Could you use a DCWorkflow instead to solve your problem?  It does
>>the Right Thing (tm) about guarding transitions with permissions or
>>roles, I think.
> 
> Yes, I could, and will.  Is DCWorkflow likely to replace the
> DefaultWorkflow in 1.2?  If not, I could make the changes above on a
> branch for now...?


Landing (and perhaps renaming) DCWorkflow as part of the core CMF
is definitely on the roadmap for CMF 1.2.


Tres.

-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com