I've been trying to test Wiki space permissions and page restrictions, to ensure that I and other users can correctly restrict pages. It seems that page restrictions behave in a strange way: if you add Joe Blogs as the only person who can view or edit a page, all the other users not mentioned in page restrictions list cannot view/edit the page. However, if you then remove Joe Blogs from that 'allowed users' list (leaving nobody in the list at all), suddenly every user can view/edit the page, although the logic of the first case indicates that nobody (apart from admins) should be able to view/edit the page. The absence of a person's name on the 'allowed users' list takes on opposite meanings, depending on whether or not anybody else's name appears in the list. Complications multiply: for example, if Joe Blogs appears on a particular page's 'View' permissions list but not on its empty 'Edit' list, he can both view and edit the page. But if his name appears on a page's 'View' list but not on its 'Edit' list (that contains at least one other name), he can only view the page; he cannot edit it. His settings have not been changed, somebody else's have; yet his access level changes.
I've been investigating this for some time now and I'm still being surprised by my test results, which does not bode well for the prospect of a casual user being able to use the permission settings with confidence. Is there a detailed document available anywhere which lists the outcome for a user in every possible combination of space and page permission settings (including the cascade effects of a parent page, the influence of other users' settings as in the above example, etc)? I don't want to have to reinvent the wheel. Or is there a way to safeguard against the issues described above occuring, some global setting that I can change perhaps?
I think aussie has a lot of good points here and he/she listed it up nicely.
This is not to say that the permission/restriction system is badly planned or not consistent. It is just to say that I also find it quite confusing at times. What might contribute to this is the combination of permissions (at space level) and restrictions (at page level).
So again, I am not saying that it is all bad but I can fully relate to the feeling that it is counterintuitive. And the good thing is: just in case I should have gotten it all wrong it just proves my point ;-)
This is an intended behavior on Confluence.
However, if you then remove Joe Blogs from that 'allowed users' list (leaving nobody in the list at all), suddenly every user can view/edit the page, although the logic of the first case indicates that nobody (apart from admins) should be able to view/edit the page.
If the page restriction is not applied on the page or it's parent page, it will follow the restriction/permission from the space permission itself. In your case, there is no restriction placed on the space permission level therefore all the Confluence user are able to view the page after the page restriction is removed.
The absence of a person's name on the 'allowed users' list takes on opposite meanings, depending on whether or not anybody else's name appears in the list.
The "Restrict to viewing to viewing this page " and " Restict editing to this page" in the page restriction means that only the user or group specify in the allowed list will be able to view or edit the page.
if Joe Blogs appears on a particular page's 'View' permissions list but not on its empty 'Edit' list, he can both view and edit the page. But if his name appears on a page's 'View' list but not on its 'Edit' list (that contains at least one other name), he can only view the page; he cannot edit it
When there is no restriction in the " Restict editing to this page", all user that are able to view the page will be able to edit the page as well. When there is a restriction in the page edit, Confluence will take that into account and only allow user that are placed in the "Restict editing to this page" list to edit the page.
This document might be useful to you.
I hope this clear your doubts.
Thank you for your response. Unfortunately the document link you provided seems to be looping back to this question page; would you mind re-posting that link?
I think I understand how the permissions are working, but I am still concerned that casual users won’t easily be made to understand it completely. Or worse, they may never come to understand it, and will leave confidential Wiki pages open for viewing by all users without realising it. In my opinion, a permissions-related action should produce a consistent and intuitive result. For example, adding a user to the list should always enable them to view the page and removing the user should always block them from viewing the page. And these actions should not impact on the viewing permissions of any other user, regardless of how many other users are (or are not) in the list.
I can see that it is useful to have a quick way to set a page’s permissions to “viewable/editable by all (unless parent or space permissions say otherwise)”; currently, the surprising reversal of the page permissions basic function, which occurs whenever all users are removed from the permissions list, does enable this. But surely this could be provided in a way that’s consistent with how the page permissions functionality generally works? For example, button/s in the permissions window called ‘Add all users’ and ‘Remove all users’, or a checkbox alongside each username with an option to ‘Select all [checkboxes]’ / ‘Deselect all [checkboxes]’? Perhaps users barred from viewing/editing the page due to parent or space permissions could appear in the list, though with their usernames greyed out. All users could perhaps be added to the permissions list by default when a new page is created. Alternatively, perhaps radio buttons could be shown alongside each username, making it clear exactly what each user can and cannot see/do on the given page: “No access”, “Viewing access”, and “Viewing and editing access”.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hi Community! Kesha (kay-sha) from the Confluence marketing team here! Can you share stories with us on how your non-technical (think Marketing, Sales, HR, legal, etc.) teams are using Confluen...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs