[Zope-CMF] CMF 1.3 roadmap / release schedule (preview)

[Florent Guillaume]

I put it back in the collector BTW, with further comments.
http://www.zope.org/Products/PTK/Tracker/482


Florent Guillaume  <fg@nuxeo.com> wrote:
> Bug 410 (http://www.zope.org/Products/PTK/Tracker/410) is marked as
> fixed but it isn't.
> 
> Here's how to reproduce the bug:
> 
> - Instrument the code in WorkflowTool.py like thus:
>          def notifyCreated(self, ob):
>              '''
>              Notifies all applicable workflows after an object has been created
>              and put in its new place.
>              '''
>              wfs = self.getWorkflowsFor(ob)
>     +        from zLOG import LOG, INFO
>     +        LOG('WorkflowTool', INFO, 'notifyCreated for object %s goes to workflows %s' %
> (ob.getId(), [wf.id for wf in wfs]))
>              for wf in wfs:
>                  wf.notifyCreated(ob)
> 
> - Create a Factory-based Portal Type named "MyDocument" based on
>   Document, without any change. (The bug will manifest itself for types
>   where meta_type != portal_type.)
> 
> - Create two workflows, foo and bar, based on any workflow.
> 
> - In the Workflow Tool, assign Document to 'bar' and 'MyDocument' to foo.
> 
> - In the CMF, go to My Stuff and create an object blah of type MyDocument.
> 
> - In your stupid.log you'll see:
> 
> 2002-03-20T15:56:28 INFO(0) WorkflowTool notifyCreated for object blah goes to workflows ['bar']
> ------
> 2002-03-20T15:56:28 INFO(0) WorkflowTool notifyCreated for object blah goes to workflows ['foo']
> 
> 
> 
> The problem is that notifyCreated is still called from manage_afterAdd
> (where portal_type hasn't been set), even though an additional one was
> added to constructInstance. But we cannot completely remove the one in
> manage_afterAdd if we want workflows to be reset when doing a copy or a
> paste...
> 
> Besides, it's wrong to have two calls to notifyCreated...
-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 10  http://nuxeo.com  mailto:fg@nuxeo.com