[Zope-CMF] Replication And Workflows - "Nightmare of CMF Street"
Dieter Maurer
dieter at handshake.de
Wed Sep 17 13:52:44 EDT 2003
Tres Seaver wrote at 2003-9-16 15:47 -0400:
> ...
> In earlier verisons of CMF, the workflow was notified that cloned
> objects had been created via the object's 'manage_afterAdd' method;
> more recent versions correct this to do the notification in
> 'manage_afterClone'. The symptom in those case was that objects would
> "revert" to the private workflow state when copied and pasted between
> folders.
>
> The behavior is apparently still not acceptable for some use cases. See:
>
> - http://collector.zope.org/CMF/176
>
> - http://collector.zope.org/CMF/184
>
> BTW, please don't reply-with-quoting to the entire digest!
In the plone-users mailing list, someone reported that imports
of complete Plone sites reset the workflow state after
he fixed "manage_afterClone" along some suggestion of mine.
I think, my fix to "manage_afterClone/manage_afterAdd/manage_beforeDelete"
should in some form go into the CMF code base:
The motivation: there should be no workflow change, no indexing
and no unindexing when an object is added/removed/cloned
as part of the *complete* CMF site.
This can be easily achieved for workflow notification:
def manage_afterClone(self,item):
workflowTool= getattr(self,'portal_workflow',None)
if workflowTool is not None:
portal= workflowTool.aq_inner.aq_parent
if item.aq_inContextOf(portal) and item != portal:
self.notifyWorkflowCreated()
....
For cataloging, it would be necessary to use CMF site relative
paths rather than physical paths in "portal_catalog"
in order to apply a similar
modification to "manage_afterAdd" and "manage_beforeDelete".
Dieter
More information about the Zope-CMF
mailing list