Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,701
Community Members
 
Community Events
176
Community Groups

Evaluating (overthinking) restricted pages vs. a different wiki space for secret stuff

I need to evaluate the pros and cons of different methods of managing access to certain content. I'm sure I'm way overthinking this but if there are additional factors I haven't considered please chime in.

The content is "advanced" but not sensitive or super-secret. It could confuse an average user of our wiki space so we'd like to limit it to a certain group of power users.

The two main options are,

  • using a separate branch of restricted pages
  • a different wiki space.

The first option keeps everything in the same space, which is good. We'd have to maintain a user group with access to the content, which is fine. I'd want to grant several others admin permissions to help with that. However, we're concerned that contributors might feel inhibited by the unlikely possibility that a permissions glitch could inadvertently expose details. And I believe (but am not certain) that if restricted pages are listed out in say a content by label macro, or search results, they wouldn't appear in the listing to someone who couldn't see those pages, is that correct? We don't want people to find inaccessible pages and try to click through to them.

The second option has greater confidence that complicated stuff stays less accessible, but there is the overhead of maintaining a second space, which is less desirable. It would be in the same instance, though.

Are there other factors I should consider? If you've made a choice like this, how did you decide?

4 comments

Dear Michelle,

in my company we are using both options without any problems.

Confluence itself would most likely not leak any information even when using macros. However you have to be careful with apps as Confluence allows apps to access all information and it’s up to app to respect access permissions. This risk applies for both of your options in the same way - evaluate apps carefully.

I hope that helps.

kind regards 

Andreas

Pages that you do not have access to via lacking permissions or restrictions will not show up in search/macro results.

My two cents would be to use a different space. I have found that managing page restrictions within a space can get hairy ... especially when restrictions get put on pages that are multiple levels deep in the hierarchy. I find it simpler to have another space.

Page restrictions are only useful when you have a solid space admin and you understand your audience.

ie.  page restrictions allow you to add anyone to the restricted page, but if they are not a member of the space, it won't work.

For the most part - I tell people to avoid them unless really needed.

My $0.02

@Michelle Rau good , we use different spaces for content with different permissions. 

Procedures that are shared between teams are put into 'public' spaces and procedures that are only applicable to one team are put into their teams' space. This makes permissions much easier to handle. 

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events