Is there a relationship between the rights ?
What I mean is that if we give ‘EDIT’ rights to a user on a nested space (this page and all its children); does this imply the user also has 'READ" and/or ‘COMMENT’ rights?
Or should we give all three the right-levels to that user (or group)?
See the Implied rights column on https://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HRightdefinitions .
Ok, but we experience some other behavior…
Case:
Nested space : PersonWithDisease
Child Nested space: ATE
Child pages: Questions asked
We have set admin.PersonWithDisease.WebPreferences (Rights Page and Children)
We have given the user EDIT rights
We got reported that user could not create new question : PersonWithDiseae.ATE.newQuestion
We changed the setting and additionally give VIEW and COMMENT rights to the user
After this change the user was able to create , edit and view the new question.
Can this be explained?
This can mean many things. Are you sure it was an access rights issue?
You need to check the access rights that were set at each level, including the ATE page.
Yes, the message was that she was not allowed to create a page.
the ATE page might be a special case and maybe causing the behavior. The full page name is generated by our custom FAQ application ‘ATE’ (Ask the Expert).
The logic to generate the full page name is that each of our Apps has a three letter code (in this case ATE) that is used to nest the resulting pages in a user-owned space.
So PersonWithDisease (=nested space) > ATE (=not existing page) > Questions asked page (end-page, no nesting below possible)
So the ATE.WebHome page doesn’t exist, but what about the preference page ATE.WebPreferences? The access rights that affect the sub-tree are stored in the preference page. So even if the page itself doesn’t exist you could have the preference page.
No nothing; The code just generates pagenames with ATE as nested space name, but the actual page ATE is never created or touched…
So our theory is that when checking the rights to create a page in such virtual nested page a user also needs view rights as extra to edit to check if there is such a WebPreference setting somewhere in the tree? But that should then maybe adjusted in the documentation that claims that EDIT on the containing space (Page and it’s children) gives you implicit VIEW rights on all pages (including WebPreferences) that sit between the containing page and the target page even when they are virtual (=non-exisiting)