This question is in reference to Atlassian Documentation: Page Restrictions
I want a user to see only one page in my space. That page is part of a hierarchy of pages. Now: how can I restrict access higher in the parent hierarchy and still give access (because inherited access rights are always blocking access, even when I give specific access on the leaf page).
I believe this system is rather problematic: it should be possible to restrict access higher in the tree, and give specific access lower.
Hi Ronny,
simple answer: you can't. No way. This was discussed a lot of time here in answers.
The only thing that might work is to put this page directly under the home page of the space and restrict all the other pages that are directly under the home page to the rest of your people.
But this is a hell of administration and very insecure. You have to restrict every single new top page of your space and never forget that...
So, I won't do that, if I could avoid it.
I also judge this way of "permission management" as insufficient. It equals the general rule for each space: "everything is allowed except for what is forbidden", i.e. a classical black list approach. For security reasons, we would prefer "everything is forbidden except for what is allowed", i.e. classical white list approach.
Is there a feature request that I can vote on to provide this feature?
I would propose to be able to switch per space between the black and white list approach. It would be ok, if a leaf page is marked as "allowed" for a user, that all the parent and grandparent etc. of this leaf in this space are automatically also "allowed", but no sisters, brothers, cousins, etc. ... in particular new sites shouldn't be accessible in whatever way by this user.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
yes, there are feature requests:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm on board that it's a flaw in the design...
Here is my work-around, it's a pain sometimes but it works.
I created a Generalized Space to house information for specific viewers and assign permissions for specific page views.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you elaborate, please? I didn't understand your approach. I have same problem.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You are right Thomas. Not only it is bad, but stupid as well, because I would create more accounts for my partners, which can be monetized by atlassian. Thank you your reply,. mu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe if you use the Include page macro on a page the user has rights to see, in that space, or a public space? I think that the Include Page macro only looks at the permissions of the source page, not its parents.
If it works, you can leave the leaf page where it is, and have a mirror of the page elsewhere, possibly a public space.
OR you have to turn the problem around, and have the source page in a public area, and then include into your private hierarchy. Yes, it is a bit cumbersome, but you only have the content controlled in one location. And if they are in separate spaces, you can keep your space secure.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.