[Zope-dev] bug in manage_pasteObjects ??

[Romain Slootmaekers]

Dieter Maurer wrote:
> Romain Slootmaekers wrote at 2003-8-28 22:14 +0200:
>  > after an object is copied & paste, the following method is called:
>  > 
>  > 
>  > def manage_afterClone(self, item):
>  >      """
>  >      """
>  > 
>  > 
>  > 
>  > 
>  > as it happens, both self and item refer to the same object.... which 
>  > severely limits the use of the method. You probably want a reference to 
>  > the original object from which this one was cloned.
> 
> I am not so sure about this.
> 
> I think, in most use cases, it is sufficient to have the copied
> object. At least for all currently handled use cases it is apparently
> sufficient.
> What use case do you have that needs the original object?

We have a content type that has 2 types of attributes:
- private attributes (private as 'not shared')
- shared attributes
    (btw, these reside in  a RDB, the object only knows a primary key)

Only the original content object can modify the shared attributes
the others can view them but only edit their private attributes

This all works fine.

We want to delete all clones automatically when an original is deleted.
For this, we need an accounting scheme that notifies the original about 
its clones. The designated place to do this is manage_afterClone, but we 
lack the necessary information in that method, hence the suggested change.

So the official use case would be:
   "clone needs to call method on original."


> 
> 
> Under no circumstances are you allowed to redefine the "item"
> parameter above to refer to the original object (as suggested in
> the quoted message):
> 
>   "manage_clone" is often implemented recursively and
>   while in the top call "self" and "item" are identical,
>   this changes in recursive calls.
> 
>   Knowing "item" (where the recursive "manage_clone" started)
>   is essential to differentiate actions depending on the
>   relative position of "item" with respect to other objects:
> 
>   e.g. initialize workflow when "item" is below the portal
>   but do not when it is above.
> 
>   Code that makes these checks will break when you pass a differnt
>   object as "item".
> 

I changed my 2.6.1 and haven't noticed any defects (yet ;)) in the plone 
that uses this behaviour.

I'm willing to run the whole testset against my changes but this will 
cost me significant setup time as I'm not a (registered) zope developer.
as the changes only affect 10 lines, I was wondering if someone else 
would 'do the honours'. :)

> Dieter

Romain