-
Suggestion
-
Resolution: Won't Do
-
None
-
927
-
64
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Edit restrictions are not inherited.
When we have a big existing space and we want to change edit permissions of a hierarchy, it's very painfull because we have to change manually the permissions of every pages of this hierarchy.
We should be able to optionally inherit 'edit' permissions so as to 'view' permissions does.
In fact, I don't really understand why you do it for 'view' permissions and not for 'edit' permissions.
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
- is duplicated by
-
CONFSERVER-52362 Edit Restriction is not inherited to child page
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Future Consideration
- relates to
-
- Gathering Interest
-
- Gathering Interest
- is blocked by
-
CSP-274612 Loading...
- mentioned in
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[CONFSERVER-5095] Page edit permissions should be inherited by pages, like view permissions are
Good on Andreas and his team for creating a plugin for functionality that should have been part of Atlassian's first release. To Atlassian, this ticket was created back in 2006, and for the past 17 years has been continually requested by your community. Notwithstanding it has taken you 14 years to end up closing the issue without even addressing it, your community asserts that the ability to inherit permissions within page trees is a fundamental need to this day. There has been enough desire that a third party has developed something you should have done almost two decades ago. How embarrassing!
Yes, we have an app for this: https://marketplace.atlassian.com/apps/1221313/edit-permission-inheritance?hosting=datacenter&tab=overview
What gets me is the rhetoric you are using to explain this is about the philosophy of 'encouraging open ways of working'. That is referring to having things open for people to see them. I can already restrict people from seeing/viewing a page and all of it's children - with NO indication that I am restricting the viewing of the child pages I make...
So perhaps Atlassian, you are missing the point of the request... The request is not about making the UX better than it currently is (as I pointed out, the existing UX already allows me to stop people from viewing child pages without any visual indication of this happening), the request is to simply allow a similar way to allow the edit restrictions to be applied to child pages.
Started reading the long winded explanation of "We don't wanna". BOOOOOOOOOO! Sure, we all use this application because of its ability to foster open collaboration. Sometimes you generate source pages that feed many others, and you don't want just anyone "openly collaborating" and breaking things. Perhaps you share a space with subcontracting companies, and you have proprietary information that you shouldn't have to expose. Perhaps you have a collaborative space with several teams working on the same pieces, but you don't want people accidentally moving stuff people are using. Perhaps you have documentation built across a deep hierarchy of pages that you want a customer to view but not change. There are too many use cases for having hereditary permissions to count.
I'm sorry, but "WhErE eNcOuRaGiNg OpEn WaYs Of CoMmUnIcAtInG" rings disingenuous at best.
I suggested this before and heard no response. Have 2 edit permissions - one inheritable and one not. Allow a one time conversion from non inheritable to inheritable. After that when you apply permissions, you will have a choice to inherit or not.
This satisfies the existing customers and gives you the flexibility to handle things the way people THINK it should work. Like the people who have many child pages that must have permissions hand set. It would not affect customers who like the way it works today, all 5 of them.
I just read the whole lengthy explanation given by the senior product owner, felt like one of those movies which runs for 3hrs and you know the story can be told in 5 mins.
If anybody has used Windows/Mac/Linux and ever set permissions on folders they would easily get the problem and solution. But I guess some really good analysis was done (for few years with some apparent customers).
So people understand that what you understand is wrong and what Atlassian is saying is the write way of doing thing.....so lets just put our heads down and start putting separate "Edit" permissions on 2000+ pages because they should never by inherited.
We run 7.4 and I am not satisfied with the result. Inheriting the one permission and don't the other is quite confusing!
Why don't you give us a managable attribute to choose for ourselves? This lack of functionality prevents Confluence of beeing a managable wiki software.
Please adjust.
Shame on you Atlassian, for not having this when someone else wrote a simple plug in to do what should be bundled in as a native functionality (https://marketplace.atlassian.com/apps/1221313/edit-permission-inheritance?hosting=server&tab=overview).
Where do you get the audacity to force all your Server users to move to Data Center while hiking up the price by double when you can't even have a core functionality like this?
What I learned from the resolution "Won't do" is "We don't care at all".