ideas to sort out the permission system #38

testbird opened this Issue Apr 2, 2013 · 1 comment


None yet

1 participant

testbird commented Apr 2, 2013

• separate the rights to delete versions (add a new delete group), and manipulate node access rights (admin group) from the publisher group.

(So plain publishers are not automatically able to delete version data and change node properties.) Consequences: For plain publishers that are not in the "delete" group, the versions table in the node properties window should not show the destroy buttons (but they should still be able to unpublish and switch published versions etc.), and the "drive" tab should not allow them to change the access rights.

• separate the user/group/acl management (admin), and non-static templates, css, img-formats manipulation (webdev) from the full rights (superuser) that include the site settings.

(So plain admins are able to manage users and change group definitions, but only webdev/superuser can mess with templates+classes or site settings.)

• When assigning a new parent node:

If the user does not have admin rights,
if the node currently inherits the access permissions,
auto-adjust the access rights from "inherit" to the specific groups, in order to preserve the permissions,
if the adjusted permissions are now the same as from the new parent node,
reset the permissions to "inherit" again

testbird commented Nov 5, 2013

Implementation Details:


"delete_group" and "admin_group" are new node attributes (formerly the publish_group had all that power)

"login-manager" new built-in group (like logged-in) or user status below admin
"webdev" new build-in group or user attribute (independent from user status ranking)

disable "Site" table access for admin status and restrict it to the reintroduced superuser status

adjust the algo to change the parent node (as in the report above?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment