nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you manage edit access for a whole page tree in Confluence Cloud?

Raúl Marín

Hi everyone,

I was trying out restrictions on a test site and noticed that if you restrict who can view a page, the pages under it show “Restricted by a parent”. Edit access doesn’t work that way, so every child page stays editable by anyone in the space unless you change it one by one.

How do you handle that on bigger page trees? Page by page, a script, an app, or moving things into their own space? And how often does it actually come up for you?

Full disclosure: I'm a developer looking into building something for this. Nothing to sell. I'll share a summary of the replies here.

Accepted answers

Gabriela - LeanZero

Hi Raúl, the Cloud doc at https://support.atlassian.com/confluence-cloud/docs/add-or-remove-page-restrictions/ confirms that edit doesn't inherit the way view does.

On my test site, a page I moved under an edit-restricted parent stayed editable, and one I moved out of a view-restricted tree became visible again, so the inherited view only holds while a page sits inside the tree.

If you script it, I'd start from a CQL search on ancestor = <id> and type = page, since the ancestor field finds "all content items that are descendants of a given ancestor", where the v2 descendants endpoint stops at depth 10. For a new build the 14 Oct changelog says "If you are building new integrations or migrating from the V1 content restrictions API, we recommend using these new v2 endpoints," which means POST /wiki/api/v2/pages/{id}/permissions. On the older v1 restriction endpoint, PUT replaces the user and group lists and POST adds to them. Atlassian is also rolling out a v1 change tenant by tenant since 15 Oct, and on pages that already have view restrictions, granting edit has to include view for the same user or group. Both entries are on https://developer.atlassian.com/cloud/confluence/changelog/ under those dates.

A script is a snapshot. Anything moved in later stays editable until you run it again.

You can also do the one-off pass in automation with a branch over the tree and the Restrict page action, but the branch stops at 1,000 pages and Restrict page takes no smart values, which is CONFCLOUD-79798, so your group has to be fixed. For later arrivals, you could put a rule on the Page published and Page moved triggers with a CQL condition of ancestor = <parentId> and Restrict page with that group, which should keep them in line. I haven't built that rule myself, so I'd try it on a test page first.

On how often it comes up, CONFCLOUD-5095 at https://jira.atlassian.com/browse/CONFCLOUD-5095 asks for edit to inherit like view and sits at Gathering Interest with 973 votes. For your research, you can't restrict content on the Free plan at all.

Tomislav Tobijas

Hi @Raúl Marín

Some great suggestions already shared here!

One thing I'd add (and which I recently tried out) is asking Rovo (specifically, I used the MCP connector with ChatGPT) to do some bulk updating, including restrictions 🔐
It works really well, although it would be better if there was just a way to simply propagate permission changes to child items as well 👀

Probably you could build a relatively simple app in Forge (or within Studio itself) that could do this 🤔

Cheers,
Tobi

All comments

Merry Curie

You have spotted the key difference correctly: in Confluence Cloud, view restrictions are inherited down the page tree, but edit restrictions are not applied to child pages in the same way, so each child page can still be edited by anyone who has edit permission in the space unless you restrict it separately.

For a larger tree, I would avoid doing this page by page by hand. The cleaner approaches I have seen work are:

1. Use a dedicated space for the restricted tree when possible, and control edit access with space permissions and a small editor group. That keeps the boundary clear and much easier to audit than dozens of individual page restrictions.

2. If the pages must stay in the existing space, use a consistent editor group rather than naming individuals, and apply the same edit restriction to the parent and every descendant. A script using the Confluence REST API can walk the page tree and apply that group restriction consistently, which is far more reliable than manual edits and easier to repeat when new child pages are added.

3. Test the result with a non-editor account before relying on it, and check child pages created later, since new pages will not automatically pick up the parent edit restriction.

In practice, the dedicated-space approach is simplest for an ongoing collection, while the scripted approach is better when the tree has to stay where it is. Either way, keeping the editor list in a group will save a lot of maintenance later.

Gabriela - LeanZero

Hi Raúl, the Cloud doc at https://support.atlassian.com/confluence-cloud/docs/add-or-remove-page-restrictions/ confirms that edit doesn't inherit the way view does.

A script is a snapshot. Anything moved in later stays editable until you run it again.

Raúl Marín

Thanks Merry. Have you used the script approach on a real tree yourself? How did you handle child pages added later, just rerun it every so often?

Raúl Marín

Thanks Gabriela, didn’t know moving a page out of a view-restricted tree makes it visible again. Have you seen teams actually run that automation rule? Wondering if the one fixed group limit gets in the way in practice.

Tomislav Tobijas

Hi @Raúl Marín

Some great suggestions already shared here!

Probably you could build a relatively simple app in Forge (or within Studio itself) that could do this 🤔

Cheers,
Tobi

Raúl Marín

Thanks Tobi, hadn’t thought of using Rovo for restrictions. Was that on a real tree at work? And when new pages get added under the same parent later, do you just ask Rovo again?

Gabriela - LeanZero

Hi Raúl, I hadn't seen a team run it, so I built the rule on my test site today, and the fixed group turned out to be the smaller problem. I was wrong on that part, since Restrict page took two groups in one action and also offers "Current user in flow" and "Flow initiator", so what you can't get is a per-page value like the owner, which is still CONFCLOUD-79798. Page moved with an ancestor = <parentId> CQL condition caught all five pages I moved in, but when I moved a page that had a child, only the moved page got locked and its child stayed editable. Page published with the same CQL restricted 4 of 11 new pages, and the audit log showed success with no action and no error, which looks like the timing problem in https://jira.atlassian.com/browse/CONFCLOUD-77888, since the same search found those pages a few minutes later. Atlassian closed a related bug, https://jira.atlassian.com/browse/CONFCLOUD-79253, about CQL conditions that sometimes fail to match, as Won't Fix with the workaround "Use the smart values instead", which is what worked for me. A smart value condition of {{page.parent.id}} equals the parent ID caught 7 of 7, though you'd still need something else for grandchildren. The action also replaces what's there instead of adding to it, so one page lost a user's edit access and another lost its view restriction and became visible to the whole space. That part surprised me most. The person the rule runs as also ended up on the edit list of each page it restricted. They need restrict rights in that space and should be someone you're happy to see there. I created those pages through the API, so I haven't tested pages made in the editor, and copies need the Page copied trigger. Are the trees you're working with mostly one level deep, or do you need grandchildren covered too?

Raúl Marín

Really appreciate you building it to check. The trees I’ve seen people describe go a few levels deep, so grandchildren would need covering too. The replace part worries me most, a page quietly becoming visible to the whole space is easy to miss. Have you seen that happen anywhere outside a test site?

Gabriela - LeanZero

Hi Raúl, thanks, and no, I haven't. Everything I've seen of it happened on my test site, so I can't tell you how often it bites on a real tree.

There's no ancestors smart value, but you can chain {{page.parent.parent.id}} even though the docs don't list it. Join {{page.parent.id}}, {{page.parent.parent.id}} and so on into one string and check it contains the top page's ID, and it covers exactly as many levels as you chain. The CQL ancestor condition does reach every level, but it still missed pages at trigger time, and this time it missed one of my moves too. A Page moved rule with the chained condition plus a Related entities branch on ancestor = {{page.id}} and type = page locked a moved page together with its whole subtree. A Scheduled rule branching on ancestor = <parentId> and type = page reached every level for me, including the pages my publish rule had missed. Each run counts a step for every page it restricts, and Confluence Standard only includes 100 steps per user a month (https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/), so I'd run it daily rather than every few minutes.

That sweep makes your worry worse, since it re-applies the replace on every run and neither CQL nor smart values can see what's already restricted. If you label the pages you've restricted on purpose and exclude that label in the sweep's branch CQL, they stay out, which held on my test. I'd also snapshot the restrictions with the REST GET on a copy of your tree before and after you turn a rule on. The site audit log lists "Content restriction removed" under Permissions with the old value (I read it through the audit API), though you need Confluence admin and it isn't on Free. It only logs the page that changed, not the children that became visible. That gap is https://jira.atlassian.com/browse/CONFCLOUD-83729. The automation audit log only says success.

Tomislav Tobijas

Yeah, it was a live environment where I/we performed this. But it was only a one-time thing. I guess we could just follow the same principle for new pages, or create some kind of AI scheduler that would do this 🤔

Raúl Marín

That’s way more digging than I expected, thanks Gabriela. Didn’t know the sweep counts a step for every page, on a tree with a few hundred pages that runs out fast. I’ll post back here what I find.

Raúl Marín

Thanks everyone, here's the summary I promised.

View restrictions are inherited down the tree, edit restrictions aren't. Pages created or moved under an edit-restricted parent stay editable by anyone with space access, and a page moved out of a view-restricted tree becomes visible again.
For a one-off fix, people use a script over the tree (CQL ancestor = <id> finds every level) or Rovo for bulk updates.
Keeping it right over time is harder. Gabriela tested Automation in detail above. The Restrict page action replaces existing restrictions instead of adding to them, publish rules can miss brand new pages, and moved pages don't take their children along unless you add a branch. A daily sweep helps but counts against your automation usage. Worth reading her posts before building a rule.
The Free plan can't restrict pages at all.
If you change restrictions in bulk, snapshot them before and after. The audit log shows the page that changed but not the child pages that became visible.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

cloud

confluence-cloud

permissions

page-restrictions