Description

When using hierarchical ACL, a user may change effective ACL by renaming a page.

Steps to reproduce

Rename a child page

1. Create a child page without acl, that inherit acl from the parent page, for example: Parent/Child
2. A user allowed to rename a child page may rename it to OtherParent/Child

Result: the effective acl change from Parent acls to OtherParent acls

Expected: user can not change acl without admin rights.

Rename the parent page

1. Create parent page and some child pages without acls, for example: Parent/Child1, Parent/Child2...
2. A user allowed to rename the parent page may rename it to Other

Result: All child pages loose their acl

Expected: All child pages "move" with the parent when the parent is renamed.

Component selection

• acl system or rename action or both

Details

1.6 should have this problem.

Workaround

Disable page renaming in the parent page by removing the delete right. For example:

#acl -All:delete

Discussion

There are actually two issues here, both related to adding hierarchical ACL on a system that only "fake" hierarchical structure.

A way to have different acls for the parent page and the children pages would solve the parent renaming issue. You can have a "locked" parent page and editable child pages.

Possible solutions:

1. Compare the effective acl of the new page name with the current effective acl, and require admin right if different. The interesting acls for a rename operation is the list of parent pages acls. acl before, page acl, acl default and acl after do not change in this case.

Open issues:

1. If solution 1 used, a user may be allowed to create a page under parent, but not allowed to move it elsewhere.

Plan

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinBug