[Zope-CMF] CMF 1.3 roadmap / release schedule (preview)
Florent Guillaume
fg@nuxeo.com
Wed, 20 Mar 2002 16:18:01 +0000 (UTC)
Tres Seaver <tseaver@zope.com> wrote:
> - Are there outstanding features / fixes which you believe to be
> critical for a "stable" 1.3 release? Note that proposing a feature
> without being willing to do (or recruit someone to do) the work to
> implement it is a futile exercise; this is not a request for
> "wish-list" items.
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
--
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com