I have just concluded an epic two day struggle with Zope's security machinery. I think I've won, and wanted to find out whether anyone else has had similar problems. I had defined a Python product that worked very nicely. I was able to add and delete my objects and edit, copy and export them perfectly well. But when I tried to rename, paste or import them, I got an exception saying that "The object X does not support this operation". It appears that security checks for permission to add an object to a Folder is done differently by the Product Add machinery and the CopySupport machinery that paste/rename/import use. I had defined my constructors slightly unconventionally in __init__.py. Redefining the constructors more normally solved my immediate problem, but it doesn't remove the source of Zope's inconsistent behaviour. More details of the diagnosis are at the end of this email, for those who are interested. Is this something I should put in the collector? One happy result of this mess is that I am now on a first-name basis with about 80% of the Zope source code! Stephen ___________________________________________ Stephen Simmons, stephen.simmons@healtharena.net HealthArena B.V., Amsterdam, The Netherlands phone +31 20 486 0555; mobile +31 6 1505 3086; fax +31 20 486 0559 Problem copying/pasting and renaming ------------------------------------ I was able to create new instances of my Element class, but whenever I tried to rename, cut/paste or import the objects, _verifyObjectPaste() in CopySupport.py raised a Copy Error (The object X does not support this operation). _verifyObjectPaste() performs three checks: (i) The container is happy having an object of this type being pasted into it (ii) The user is allowed to create new objects of this type (iii) The user is able to access the object being pasted or renamed All three conditions were true, so there is no reason why renaming, etc should be prevented. Especially when I could create objects as desired through the management screens. Solution -------- The problem was traced to the unusual way I had defined the constructors in __init__.py and the class's module. It appears that getSecurityManager().validateValue(meth) does not exactly duplicate the check done when adding a product instance. Originally, I removed the constructor definition tuple from __init__.py: def initialize(context): """Register Element""" context.registerClass( PlatformElement.Element, constructors = (PlatformElement.Element), # Specified indirectly! icon = element.gif ) and put it at the end of my class definition module, PlatformElement.py: class Element(Folder): ... def manage_addElement(self, id, name='', title='', REQUEST=None): """Create an Element""" ... Element_constructors = ( ('manage_addElementForm', HTMLFile('Element_add', globals())), ('manage_addElement', manage_addElement), ) In this case, check (ii) was failing at line 390 of CopySupport.py when trying to validate the constructor manage_addProduct/HAPlatform/manage_addElementForm. The problem was fixed by changing the constructor definition to the more conventional form: In __init__.py: def initialize(context): """Register Element""" context.registerClass( PlatformElement.Element, constructors = ( # Specify constructors explicitly! PlatformElement.manage_addElementForm, PlatformElement.manage_addElement, ), icon = element.gif ) In PlatformElement.py: ... manage_addElementForm = HTMLFile('Element_add', globals()) def manage_addElement(self, id, name='', title='', REQUEST=None): """Create an Element""" ... While this fixes the problem, it leaves unresolved the question of why Zope's security machinery was happy using the original constructors but barfed when checking whether it could use them.