I got a strange problem on one of our Plone (4.3.7) instance. While
users may create, edit and move contents (tested with folders, pages and
files) in their personnal folders (/Members/foo and below), they cannot delete those objects.
Trying to delete objects under or below /Members/foo raises:
------ 2015-11-18T10:23:07 ERROR Plone Traceback (most recent call last): File "/srv/plone/buildout-cache/eggs/Products.CMFPlone-4.3.7-py2.7.egg/Products/CMFPlone/PloneTool.py", line 1252, in deleteObjectsByPaths obj = traverse(path) File "/srv/plone/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/OFS/Traversable.py", line 317, in restrictedTraverse return self.unrestrictedTraverse(path, default, restricted=True) File "/srv/plone/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/OFS/Traversable.py", line 251, in unrestrictedTraverse next = guarded_getattr(obj, name) Unauthorized: You are not allowed to access 'Members' in this context ------ 2015-11-18T10:23:07 ERROR plone.transformchain Unexpected error whilst trying to apply transform chain Traceback (most recent call last): File "/srv/plone/buildout-cache/eggs/plone.transformchain-1.0.4-py2.7.egg/plone/transformchain/transformer.py", line 48, in __call__ newResult = handler.transformIterable(result, encoding) File "/srv/plone/buildout-cache/eggs/plone.protect-3.0.15-py2.7.egg/plone/protect/auto.py", line 163, in transformIterable return self.transform(result, encoding) File "/srv/plone/buildout-cache/eggs/plone.protect-3.0.15-py2.7.egg/plone/protect/auto.py", line 267, in transform root = result.tree.getroot() AttributeError: 'list' object has no attribute 'tree'
I checked our workflow (only marginally different from the intranet worflow) but I did not find anything useful :
- /, /Members, /Members/foo, and below are all in state "internal" with nothing on their "Sharing tab" but the "inherit permissions" ticked.
- when in the internal state the workflow gives Owner all of the 4 classic permissions (hence even "Modify portal contents"),
- on the ZMI/Security page, the "delete objects" permission is given to owner and acquired (this page has only default settings anyway, except for collections which comes from the fact that the instance had been deployed pre-new-style collections.).
- I checked the ownership_form of /Members/foo and every folder is owned by its respective user
- the problem occurs is not related to a specific user (I checked with 2 or 3).
- the problem disappears if the user is given the "Site Administrator" role.
The most strange behaviour is we can cut contents from the /Members/foo hierarchy and paste it to some other place on the web site (provided we have sufficient rights).
Given the fact that the Site Administrator role solves the problem, I compared very carefully the permissions of Owner vs Site Administrator and, while there are logically some differences, none relates to some permissions I imagine could be related to our problem; besides, as told above, the ZMI "Security" tab is unchanged hence those differences are the same on a newly created instance - that does not show the problem.
I'd greatly welcome any help because I cannot see what could be wrong or what I could check.