Permissions ordering: By design?

I have an XWiki instance that uses groups as users for sub-pages under the home page.

The home page is read only and can be seen by everyone, but each group has their own sub-pages under the home page.

To achieve this, I allow Edit permission for all of the groups on the home page, but deny Edit for XWikiAllGroup (we use in xwiki.cfg - there are no unauthenticated users). Like this:


I recently added a new group, added a user to it, and granted the edit right to the home page to the new group like in the above screen shot, but the new user could not view the home page.

The Admin Tools extension provided the clue as to why the new user could not see the home page: The Rights on space Main did not have the Deny permission ordered last in the list, like this:

To fix this, I edited the right for the home page, removed the Deny from XWikiAllGroup, then added it back again. After this, it worked as I was expecting - the Deny permission was last again.

I was wondering if this behavior is by design? It sure caused me confusion for a while.



As is often the case with rubber duck problem solving, I was thinking about this issue and ended up redesigning the permissions for the home page:


This is effectively the same as the previous configuration but doesn’t depend on a Deny permission or a specific permission ordering.

I’m still curious about the permission ordering, though.



Cool that you found it, was going to suggest to not use Deny! :slight_smile:

The rules are here:

Does that answer your question?

The trick is to understand the following from :

  • When a right has been allowed at a given level, it gets implicitly denied to anyone else at the same level. Using this implicit deny behaviour is recommended over applying explicit denial.