NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

Hi everyone

First of all, apologies for the time between updates and thank you for the ideas and feedback you have provided in these comments. It’s always helpful to understand how you work and how we can improve Confluence to better facilitate that. We have decided to close this issue as we won’t be addressing it in the foreseeable future. I wanted to take the opportunity to explain why.

Atlassian’s products are founded on encouraging open ways of working for all of our customers, and that influences many of the decisions we make about individual product features. Depending on the way that your teams work, you may find that this “open” model does not suit and we have seen that reflected in several feature requests.

This request has been open for nearly as long as Confluence has existed, and has been looked at by many Atlassians over the years. More recently, we planned and explored ways to resolve this and other permission-related challenges through research and design work. We took these opportunities to speak with a number of customers to validate use cases and ideas.

That brought us to a series of conclusions. Information often has a specific audience, and Confluence provides granular permissions controls, so that the right people can see the right content. This can get complicated, as it may include modifications to site and space level permissions, and/or page level restrictions that can be applied at a parent or child page level.

Changing Confluence’s model to offer edit permissions inheritance (in the same way view permissions are inherited) wasn’t the right way to address these needs:

• Some customers rely on the way restrictions currently exist to lock down top-level pages and allow child pages to be open; we didn’t want to adversely affect those that need to have Confluence work this way.
• Providing an option and explaining the ramifications of view/edit restriction decisions in a single dialog box is challenging, particularly when permissions are also in play. Over the last year we have made material progress on improving transparency of permissions, but that also served to demonstrate the complexity of messaging needed for possible different scenarios.
• Through multiple rounds of design and customer feedback, there wasn’t a solution that passed our high quality bar for setting restrictions that allowed users to quickly and easily make decisions and understand the impact of them.

That said, we have considered multiple other approaches. Each of these has had significant development estimates, and these types of changes are continually prioritised against other improvements on the basis of which would provide more value to more customers.

As a result of this process, in Confluence Server and Data Center 7.3 we released a number of key features which addressed multiple other permission issues and requests which affect a large proportion of our customers; making it clearer who is able to view a page (Confluence Server and Data Center) and enabling admins to troubleshoot permission issues (Confluence Data Center). I know that you may find this disappointing and small consolation, given we’ve not met your specific request.

In the interests of being open, I wanted to provide this lengthier update and give you some clarity on this issue. Please know that we do read and listen to your feedback, even if we are not able to address the comments on issues. This is one of many channels that we have and take into consideration when determining our roadmap and we always appreciate your feedback.

Thanks

Makisa | Senior Product Manager, Confluence Server and Data Center