The Atlassian Community Forums are currently in read-only mode. We will be relaunching on a new platform on September 22 (read more here). We apologize for the extended downtime. For concerns or questions, please email communitymanagers@atlassian.com. See you on the other side, on the new Atlassian Community Forums! :)
Atlassian Team members are employees working across the company in a wide variety of roles.
August 9, 2023 edited
Hello community members!
We’re Deborah and Nidhi, Product Managers on the Confluence Permissions team. We’re exploring comprehensive permissions improvements to relieve user frictions and simplify workflows. We need your feedback to help us define and prioritise permissions improvements.
Help shape the future of Confluence Permissions
How do you use permissions today? Are there any thorny problems related to permissions that impede collaboration with your team? Any common gaps in permissions you want to surface?
Let us know your thoughts!
We’re collecting feedback in a few different forms:
Reply to this community post: We will include these in our post-research analysis and findings.
I am not involved in the process of populating permissions groups so I can only provide feedback from the space administration point of view.
Our firm uses ActiveDirectory groups which are coupled with Crowd.
Our Confluence spaces have three of such groups per space: viewers, editors and administrators.
To restrict access typically one sets permissions of the parent page to certain groups. Incidentally permissions are set on an individual level.
This set-up serves most use cases well. The only thing I miss as a space admin is to easily see who is in each permissions group. As a workaround I make a page in the "editors only" section of the space and insert a user group macro for each permissions group.
