[Zope3-dev] Rename, Move, Copy Part II

[Jim Fulton]

The RenameMoveCopy (http://dev.zope.org/Zope3/RenameMoveCopy)
proposal proposed a basic framework for supporting object rename,
move, and copy.  That proposal has been implemented.

The proposal was silent (or quiet) on the following two issues:

- Security

- Semantics of moving ot copying containers

The current implementation largely ignores security. If you have
permission to use a container's contents view, you have permission
to make copies and, thus, potentially, to read any object. (This
assumes that you can copy an object to a location in which you have
the necessary permission.)  Of course, it is unlikely that you
have the ability to use a contents view and not have permission to
read the items, but it could certainly happen.

I suggest that when an object is copied, it should use a secure
serialization mechanism.  There will be an IShallowCopy interface.
We will be able to copy objects only if we have the necessary
permission to do a shallow copy of the objects and all of their
subobjects. This will require making security assertions like:

   <require permission="whatever"
            interface="zope.app.interfaces.copy.IShallowCopy"
            />

I also suggest that to move an object, we must be able to copy it, as
described above.

When moving or copying containers, I think we should notify contained
objects that they have been moved or copied.  There are a number of
reasons for this. Most importantly, if any paths are stored for an
object, these paths needs to be updated:

- The object hub needs to be notified that objects have moved

- Paths stored in objects like dependeble annotations, configuration
   objects, and event services need to get updated.

The current interfaces for copying and moving provide methods for
testing whether a copy or move is possible and for doing the copy or
move.  For moving objects, this is not enough.  When we move a
container, we don't want to move the contained objects, since they
have already been movee. We simply need to notify them that they have
been moved.

I suggest extending IObjectMover with a moved method::

   def moved(source, oldname, target, newname):
       """Notify an object that it has been moved
       """

The moved method will call the manage_beforeDelete and manage_afterAdd
methods on an I(Add|Delete|Move)Notifiable adapter of the object. The
method is also responsible for publishing an IObjectMoved event in the
context of the original container.  Finally, it should recheck any
containment constraints, in case the containment is not permitted in
the new location for security reasons.


and extending IObjectCopier with a copied method::

   def copied(source, oldname, target, newname):
       """Notify an object that it has been copied
       """

The copied method will call the manage_afterAdd method on an
I(Add|Copy)Notifiable adapter of the object. The method is also
responsible for publishing an IObjectCopied event in the context of
the original container.  Finally, it should recheck any containment
constraints, in case the containment is not permitted in the new
location for security reasons.

Thoughts? Comments?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org