[Zope-CMF] Workflow's 'notifyCreated' message gets sent to wrong workflow

[Florent Guillaume]

Arg, this one is pretty bad indeed.

It means that portal_type has to be set juste after object creation and
*before* the object is _setObject'ed, and this would mean redesigning
everything up to manage_addProduct... no way.

Or every CMF product's __init__ should be able to set its portal_type
itself, which defeats the purpose of the Types Tool. No way either.

So we're stuck with workarounds. In PortalContent manage_afterAdd should
not call notifyCreated and indexObject if portal_type is not set. And it
would be _setPortalTypeName's role, or maybe rather constructInstance's,
to call notifyCreated and indexObject (and we could get rid of
ob.reindexObject() in constructContent, which is there for similar
reasons).

Which, now that I reread you mail, is exactly what you propose :) But
note that manage_afterAdd still has to be there and do the work if the
object is not brand new (think about moves/copies).

I don't see how to do it in a cleaner way...

Florent


Jeffrey P Shell  <jeffrey@cuemedia.com> wrote:
> http://www.zope.org/Products/PTK/Tracker/410/1
> 
> I made a custom workflow object in Python and it's been going 
> pretty well - until I noticed that its 'notifyCreated()' method 
> never gets called.
> 
> After tracing through the creation process, I noticed that 
> notifyCreated is called in 'PortalContent#manage_afterAdd()', which 
> is called from 'OFS#_setObject()' which is usually called in the 
> factory method defined for the object, unless the objects Meta type 
> and target Portal Type happen to line up.
> 
> This occurs BEFORE _setPortalTypeName() is called on the object, 
> leaving it free-floating from its workflow (or anything else that's 
> Type-dependant) during the manage_afterAdd() process.
> 
> Thus, the permission/role mappings I had set up for my content 
> object's initial state never get set, exposing actions to people I 
> hadn't intended on.
> 
> I imagine that most of what's in PortalContent#manage_afterAdd() 
> could be moved into constructInstance, or a CMF equivilent of 
> 'manage_afterAdd()' such as 'afterConstruction' could be put into 
> the basic PortalContent API, with the intention that it gets called 
> at the end of constructInstance after the PortalType information 
> has been set.
> 
> Jeffrey P Shell, jeffrey@cuemedia.com
> 
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
> 
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
> requests
> 


-- 
Florent Guillaume, Nuxeo SARL (Paris, France)
+33 1 40 33 79 10  http://nuxeo.com  mailto:fg@nuxeo.com