[Zope-CMF] Replication And Workflows - "Nightmare of CMF Stre et"

[Norfleet, Sheppard S.]

Dietur,

I think _setObject is not the problem after all.  I am wondering if the
location of my replication product and the use of physical paths is causing
the problem.  
(root/)
staging/
   replicator_product
   staging_tool
   version_tool
   lock_tool
   versionrepository
   Stages/
     dev/
       site/
     review/
       site/
     prod/
       site/

   The page templates used in CMF acquire the replication product like
below:
    
   document_edit.py
       ...
       if form.mirror_item and not context.mirrored:   
           context.replicator.replicateCreate(context)
       elif form.mirror_item and context.mirrored:
           context.replicator.replicateModify(context)
       elif not form.mirror_item and context.mirrored:
           context.replicator.replicateRemove(context)
       ...

In the replication product I store the object as a physical path, which will
be unrestrictedTraversed to later using Moniker's bind (actually done in a
separate thread), from there the object will be replicated.  

Well heres the deal, when I get the object originally, replicateCreate(), I
cannot see the workflow_history attribute, and later when I traverse to the
object's path and recover the object in a separate thread,
checkReplicationQueue(), I still cant see the workflow_history attribute;
yet , through the web I can as I changed WorkflowTool to print (to the
console) the workflow_history attribute when it retrieves it.  


So now I am sure its not _setObject, but something in the acquisintion
engine is preventing me from accessing the attribute, and the only thing I
can see funny about it is that it uses a PesistantMapping attribute as
opposed to standard dictionary {} attribute.

Thanks so much for anything you can shoot my way.

Regards,

Sheppard
       
    



-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Wednesday, September 17, 2003 1:53 PM
To: Tres Seaver
Cc: Norfleet, Sheppard S.; 'zope-cmf at zope.org'
Subject: Re: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Street"


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