Various things on permissions

Help / Discuss
1

Hello there

I now start to interact with the permission part … :slight_smile:

A few notes and questions to this:

There is a “strange” behavior to inherited permissions which is probably a bug … I have:

Group A that contains User A
Group B that contains User B
Group “Employee” that contains both User A and B

Page “Root” : Group Employee Read, Comment, Edit

Page “Subpage of Root”: No Rights
Expected behavior: User A and B are able to Edit
Result: OK

Page “Subpage of Root”: Group A Read, Comment, Edit
Expected behavior: User A is able to Edit, User B has no access at all
Result: OK

Page “Subpage of Root”: Group A Read, Comment
Expected behavior: User A is NOT able to Edit, User B has no access at all
Result: not OK, since explicit permissions set to Group A, but inherited permission still apply from group “Employee” (probably since user A is also part of the Employee group)

I believe this is not how it should behave … my understanding is, that if there are any explicit permission on a page, this will rule out any inherited permissions, which is not the case here …

Unrelated Suggestion:
There is already a Info box on both, “Page” and “Page&Children” Admin Page emphasizing on the different sections… Maybe make it a warning or error box for the Page&Children section …

Another:
Why is the “admin” right only available on “Page & Children” and not on in the “Page” section?

On this page:

there is mentioning of “Default status”. I assume this relates to a default setup of xWiki e.g. the default permission of the “XWikiAllGroup” Or is there any other implicit implications of this like if there are no settings at all, it is deny or allow? Don’t have an unaltered instance to play …

Note: I took the liberty to add a tabular view of the permission on the page above - doesn’t look as nice as in xWiki 11. If you don’t deem it useful, just revert the page version …

Another thing related to permissions: Group memberships …
To update a group membership, one need to edit the group (page). But if one does hit “Cancel” on that page, changes to the group membership are still applied, E.g. after add/remove, every time a new version is generated … not sure if this is the intended behavior … maybe I asked already … don’t remember :innocent:

Thanks

2

Assuming Page “Root” means Page “Root” and children, then:

  • User A has edit?
    • Checks edit restrictions at the level of “Subpage of Root”. No edit restrictions so goes upwards.
    • Checks edit restrictions at the level of “Root”. Explicit edit right given to group Employee which User A is part of so return true
  • User B has edit?
    • Same as for User A (see above)
  • User B has read?
    • Checks read restrictions at the level of “Subpage of Root”. Explicit read right given to group A which User B is not part of so return false

Yes, User B can have edit right and not view right (because deny view doesn’t imply deny edit).

I think because there’s no real Page Administration ATM (see Loading... ). There’s only “Page and children” (a.k.a. Space) administration.

It may not be the best behavior, but it’s the intended behavior (for now). Changes like add and remove member are live (they are applied right away).

3

Thank you @mflorea for the swift reply.

Ok, I added some further details o the permission case:

Group A that contains User A
Group B that contains User B
Group “Employee” that contains both User A and B

Page “Root” : Page&Child permissions: Group Employee Read, Comment, Edit

Page “Subpage of Root”: No Rights
Expected behavior: User A and B are able to Edit provided by inherited Employee group
Result: OK

Page “Subpage of Root”: Group A Read, Comment, Edit
Expected behavior: User A is able to Edit, User B has no access at all (since new permission is blocking)
Result: OK

Page “Subpage of Root”: Group A Read, Comment
Expected behavior: User A is NOT able to Edit, User B has no access at all
Result: not OK, since explicit permissions set to Group A, but inherited permission still apply from group “Employee” (probably since user A is also part of the Employee group). I expected only read and comment, but not edit, as edit is not part of the permission of this subpage…

Does this make more sense? The problem is, that the inherited permission from the “root” page “employee” group “bleeds” through to the absolute permission of the child page - if this is the way it works …

Or the other way around: inherited permissions of the same group that are also applied to a child page are summed …

Thank you

4

This doesn’t restrict edit right in any way. You’re just restricting view and comment right to the Group A. When you restrict some right (e.g. view) at a lower level (some child page) it doesn’t overwrite all the other access rights (e.g. edit) inherited from the parent page. In only overwrites that specific right (e.g. only view).

5

… and there is the point where I have the “problem” with the permission thingy …

In the above, the “Employee” permissions are not inherited, since there is a new permission set on the child.

But in the case where the same group is set in the inherited and the child, the permissions are additive …

Doesn’t sound right to me or the other way around, I still don’t get the logic around it.

6

OK, after reading your comment again with a bit more time as when traveling, I get it … sometimes one has a specific view of something and then act stubborn …

Also from the Access Rights documentation page:
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 behavior is recommended over applying explicit denial.

I extended the documentation with your input from above:

When a right has been allowed at a given level, it gets implicitly denied to anyone else at the same level. This only applies to the right allowed. If only “View” is set to a user/group at this level, all other rights like “Edit” are still inherited. Using this implicit deny behavior is recommended over applying explicit denial.

Thank you very much for taking the time to explain this in depth.

7

Exactly. I’m glad I could help.