| Table of Contents |
|---|
What is it?
The Edit Permission Inheritance App allows to inherit the edit permissions defined on a page down to all of its child pages. The app does not introduce an additional permission level. It basically copies the edit permissions to all child pages and takes care of added pages.
Legal and policy documents
The following legal documents apply for all of our apps:
Getting started
Please follow the below steps to define your first edit permission inheritance:
Step | Screenshot |
|---|---|
Navigate to the parent which shall be the starting point of your "edit permission inheritance". | none |
Define the edit permissions as needed | none |
Click on the Edit Permission Inheritance Icon |
|
Turn on "Edit permission inheritance" at the top of the dialog. |
|
Select additional options if needed (for details refer to the next section). |  |
Click "Apply". |  |
The app now starts inheriting the edit permissions to all descendants of this page.
| Info |
|---|
The app is applying the inheritances intentionally slow. Please consider ~1 second per descendant before the inheritance is completed. |
| Info |
|---|
Due to the Confluence Cloud architecture you might not see inherited edit permissions on descendants without reloading a descendant page. |
The edit permission inheritance options
Option selected | Inheritance behavior |
|---|---|
None | When you hit the apply button all descendants get the same edit permissions as the parent page. Additional edit permissions are kept. |
Remove additional edit permissions during inheritance | Same as "None" but additional edit permissions on child pages are removed. |
Always grant an edit permission to the creator of the page | Same as "None" but the creator of a page will always get an additional edit permission. |
Only apply edit permission changes not the whole set | Same as "None" but only the edit permission changes done on the parent page are inherited not the whole set. This might be useful in case you changed the permissions of child pages and don’t want to loose those changes. Example: in case and edit permission was already present on the parent page before the change of permissions and is still present after the change but the current child page does not have that particular edit permission it will not be added in case this option is selected as nothing changed on the parent side. |
Delay the application of the inheritance | Delay the start of the inheritance process by 2 minutes (could be subject to change). This option can be used in case the app runs into conflicts with other apps. |
Messages shown in the edit permission inheritance dialog
Message | Further explanation | ||
|---|---|---|---|
| This message indicates that an edit permission inheritance is still being processed on this page. You should calculate with ~1 second per descendant. 💡 The message is NOT updated. You have to close the dialog and open it again. | ||
| This message indicates that the edit permission inheritance was successful:
💡 Please remember that descendants might still have their own permissions. This message does NOT mean that all child pages have the same set of edit permissions. 💡 The browser console shows all sub-inheritances and all page Ids at which the application of edit permissions has been omitted. | ||
| This message indicates that the edit permission inheritance was not successful or that descendants exists which have not been covered yet etc. The message also indicates the number of descendants which might not be in compliance and indicates the page Ids of the first 5 descendants which do not comply. 💡 You can use the offered link “Fix those pages” to fix the affected pages. | ||
| This message indicates that you can’t perform an edit permission inheritance as you don’t have a personal edit permission (an edit permission for your name). You have to add a personal edit permission first and then come back. 💡 The personal edit permission is needed due to technical reasons in Confluence Cloud. |
Understanding the way the app works
What the app does
The app adopts all edit permission on child pages (if not subject to another branch holding an edit permission inheritance) to match the parent page (the page the edit permission inheritance starts). The options selected modify the way the app does this.
When pages are added to the branch covered by an "edit permission inheritance" their edit permission set is modified to match the inheritance.
When pages are moved into a branch covered by an "edit permission inheritance" their edit permission set is modified to match the inheritance.
The app uses the closest active "edit permission inheritance". This allows you to define additional "edit permission inheritances" below other ones.
What the app does not
The app does not hinder you from changing the edit permission on child pages. However when you re-apply the "edit permission inheritance" your changes might be lost depending on the selected options.
The app does add an additional layer of permissions.
The “no view permission” case
The app does not inherit edit permission to pages which at which a view restriction hinders this.
Example: you want to inherit the edit permissions of page 1 which allow the users A and B to edit the page. On of the descendants (page 1.1) however is only viewable for user A. The app will then not grant B an edit permission on 1.1 as this edit permission would allow user B to view 1.1 - which would be a security issue.
💡 View restrictions of the starting page of your edit permission inheritance or any ancestor of this starting page to not influence the way the app works.
Advanced use cases
Use case | Solution | ||
|---|---|---|---|
I want to inherit the edit permission but want to exclude a branch. | Define two edit permission inheritances. One on the head of your “tree” the other one on the head of your “branch”. The edit permission inheritance of the “tree” will skip the “branch”. | ||
I want to inherit an edit permission for the whole space. | Despite the fact that the can handle this you should consider to change the space settings instead. | ||
I want to know on which pages an edit permission inheritance is configured. | Perform an advanced search like the following:
|
We continuously amend this list.
Frequent support cases
Observation/Question | Explanation/Answer |
|---|---|
I started an inheritance on a page with many descendants. It seems to take a lot of time before all child have the proper set of edit permissions. | The app is intentionally slow not to over-stress the interface to Atlassian Cloud. Please consider something around 1 second per descendant/child page. |
I checked whether a child page got the inheritance - but it has not. | There are a couple of things to check:
|
How to migrate from Server to Cloud? |
We continuously amend this list.
Known limitations
Edit Permission Inheritance does not handle edit permission changes performed by app users*)
Edit Permission Inheritance does not handle page added or moved events performed by app users*)
*) if the apps performs those actions as a regular user no limitations apply
Getting support
Please use our ticketing system to create a support ticket regardless whether you found a bug, have a feature request or questions.