Confluence documentation says permissions on a parent page will be inherited by a child page. However, apparently, sub-pages under a parent does not inherit the edit permissions - only the view permissions. We found online where Confluence developers explained they weren't going to fix that because it takes away from Confluence being open and made for collaboration.
Is this true?
In an environment where multiple teams create multiple projects on a single instance and must, by law,keep their data, communications and attachments private - how is this a good thing?
Is there a way around this?
Hi James,
in Confluence there are two concepts of security on different levels.
Concept one relies on permissions and it is applied to the lower levels system and space. Permissions always add up. So on system level when a user is in group A that has permission to login and in group B that has permission for administration the resulting permission set is both. Same principle on space level. When group A is allowed to edit pages and group B is allowed to delete attachments any user who is member of both groups is allowed to do both actions.
In the most top level (pages) there is another concept that relies on restrictions. Restrictions also add up but in a negative way when you think in the terms of permissions. With page restrictions you basically revoke all permissions which are inherited from the space (or the parent page) and then you can choose a set of users or groups which are allowed to read or modify the page. This restrictions apply to the page where the restriction is set and to all subpages. So the subpages inherit a reduced set of permission if someone wants to use the term permissions here. When you set up restrictions on a subpage you can only narrow it down to a smaller group of people. So when you have three pages. Let’s call it grandpa, father and son. Grandpa inherits it’s permissions from the space and adds restrictions that only user A and user B can read it then this is also applied to father and son. When father has restrictions that only user A and C can read then this page and all subpages (son, daughter, grandson, ...) will result in only user A can read as user C is already locked out by grandpa.
I hope this explains the terms permissions, restrictions and inheritance a bit. Don’t ask me what happens with cousin Al. https://www.urbandictionary.com/define.php?term=Cousin%20Al&=true&defid=14594355
I write too much. Others are faster ;)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Confluence is using 3 levels of permissions, global permissions (the "can use" permission), space permissions which allows you to control what groups and users can do in a space, and then you have page restrictions. And yes, the edit page restriction is not inherited by child pages, only view restrictions are.
If you have multiple teams on the same instance you can control their access to a space by setting the space permission to only allow team a to access it, and then restrict specific pages further if needed by using page restrictions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well wouldn't setting view permissions on a page tree accomplish this, keeping content private except for the designated few?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, the description is true.
You want the view permissions to cascade down in this way - if you don't you have no hope of anyone keeping anything remotely private as it becomes a complete free-for-all.
I am less convinced by the edit cascading idea. I err on the side of "explicitly let people edit" as it seems more simple to grasp, and just because I let someone edit one of my pages in a tree does not always mean they should be able to edit everything beneath it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Florian @Nic Brough -Adaptavist- @Mikael Sandberg @Bill Bailey -
Thank you all for your answers.
We had gotten a pretty complex "library" environment from the customer that had different permissions and groups of permissions woven thru it. I thought we had it and then, belatedly discovered the view VS edit reference in the Confluence documentation - which is why I was so upset.
Again, thanks for your replies. I really appreciate them.
Jim
PS cousin Al is another problem. . . .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
PPS - If I could Accept all 3 of your answers I would have.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, as additional information I leave you the issue where this problem was analyzed that personally I still do not understand the solution
https://jira.atlassian.com/browse/CONFSERVER-5095
Greetings,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.