Restricting view access to all pages
Asked by Darren Joyce:

We have full edit access to all our pages for Confluence users (let's call it Group1). We have a scenario where we need to allow a separate user(s) access to some specific subpages, but not view access to all pages (We will call these people Group2)

However there does not seem to be capability for this. Whenever we try and add a individual user, it says the user needs to be added at Parent page, but the parent page is the top level, and if we give access to that level, all sub-pages become viewable. if I try adding Group2, it accepts it, but it doesn't grant access.

I've tried turning on at top parent level edit access for everyone, and also tried setting edit for Group1 only, and then adding Group2 to the subpages. Neither works.

Any advice appreciated.


Answers:
author: Thomas Bowskill
body: Hi [@Darren Joyce](/t5/user/viewprofilepage/user-id/1801145)

Page permissions inherit for view access: that is, if you cannot see the parent page, you cannot see the pages below. This can make management of permissions complex if you want to grant access to only certain pages within a tree (and impossible if these pages sit underneath pages you want to restrict).

Your easier option here is to change the hierarchy of pages in your space: arrange it so that the content from "group 2" is broken out into its own page tree (next the the "top level" you mentioned). You can do this by [moving the page](https://support.atlassian.com/confluence-cloud/docs/move-copy-and-hide-pages/). This might break the structure of your page tree, so you could consider using the [Include Page macro](https://support.atlassian.com/confluence-cloud/docs/insert-the-include-page-macro/) in your "group 1" tree to give the appearance of everything falling under there. That would be my approach (and I'd consider splitting the content into separate Spaces if the material was that sensitive).

comments: author: Darren Joyce
body: Thanks for the assistance and ideas. Our top level is the Welcome page, and all content sits under there. So there is no way to move the Group2 data to that same level, as it always wants me to move it to Welcome.

The content is documentation relating to a subsystem that we have a 3rd party that will assist us, so we don't want to break it out to another Space as that starts to get a bit of a big overheard, especially if we have other 3rd parties assisting us - could potentially end up with lots and lots of spaces with only a few pages in each.

The same if we move it to the top layer - data starts to get disjointed to where it's stored.

Our breadcrumb path is

IT \> Pages \> Welcome \> (Group 1 Pages)

the page we want to allow access to is

IT \> Pages \> Welcome \> (Group2 and Group 1 pages)

Is there any other solutions?


author: Thomas Bowskill
body: Not a huge amount that I can add on top -- I've encountered the same issue and you do end up with content sitting outside of an ideal structure, which, you're right, does cause overhead. For me, when Confluence instances start to get large, I find the best thing to do is ensure people name things correctly, and to start getting people into [the habit of using labels](https://support.atlassian.com/confluence-cloud/docs/use-labels-to-organize-your-content/). I do this to reduce any dependency on the page tree for navigation, but it requires much more discipline, awareness and supervision (however, it's really, really useful when done right).

Is your 3rd party going to be continually involved, or are they part of the project that will close (i.e. could you move their documentation back into the correct structure once they've disengaged?).

Hope this gives some level of assistance -- always hard to know what works / doesn't without having a proper grasp of what is being documented.

(On your first para: RE "wants me to move with to Welcome" -- if you reorder pages, you can create a second top-level this way. If you use the move functionality you can't, but reorder will let you click and drag a page to the same level as your top page.)


author: Darren Joyce
body: We do use labels quite heavily, and that's the preferred mechanism, so the 'tree' is a bit messy as it's not that relevant (well it is some people... :) ) . With permission setting it is needed unfortunately.

The 3rd party would be working with us indefinitely, so can't separate off the documentation unfortunately.

Your re-order page functionality trick seems to have worked though! It's the closest thing to what I was after, and since we try and promote labels over folder structure, it might not have a big impact :)

I really appreciate your help - one stress over with now for me! :)


author: Thomas Bowskill
body: Glad some of it helped :) Good luck \& let me know if you find another approach, as we share the same challenge!


Tags: cloud