[Zope-CMF] Replication And Workflows - "Nightmare of CMF Street"

[Dieter Maurer]

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