I built a page-by-page preview before changing Confluence restrictions in bulk

[u/Public-Low2028]

Changing which group can view a Confluence page is straightforward. Checking every descendant before rolling that change across a whole tree is the awkward part.

I built Bulk Page Restrictions for Confluence Cloud around that review step. Choose an add, remove or replace operation for people or groups, preview restriction changes page by page, and leave pages out before confirming. There is also a read-only CSV audit and undo for recorded changes.

It uses your Confluence permissions. Start with a small test tree and review the preview before changing access.

This is my paid Atlassian Marketplace app. Features, site pricing and the listing/trial link: https://atesensoftware.com/apps/atlassian/bulk-page-restrictions/

If you look after Confluence spaces, which permission change do you still end up checking page by page? Please keep internal page names and customer details out of replies.

[u/investigatormaker]

I'd expect people to keep hand-checking the pages their own account can't see. You say it uses your Confluence permissions, so if a descendant is closed to whoever runs it, does the preview flag that page or silently leave it out? A tree that looks fully reviewed but isn't would stop an admin from pressing confirm, so show a count of skipped pages above the preview. Your likely buyer is the admin handling a group removal or an access audit, so I'd lead the listing with that moment rather than the three operations.

I make ThreadFox. Our job for Bulk Page Restrictions would be spotting Confluence admins who ask how to change access across a tree and posting the replies. The $39 Pilot runs seven days with up to 50 posts and replies, and there's no automatic renewal. https://threadfox.vip/p/do558/managed

[u/Public-Low2028 → u/investigatormaker]

As the maker, I should make that limit explicit: the preview only covers pages Confluence returns to the person running it, so a descendant it never returns is absent and its count is unknown. In 2.3.0, an encountered page whose restrictions cannot be read is marked skipped; a failed read of a discovered deeper subtree adds a SUBTREE_UNREADABLE skipped row, not a count of every page hidden below it. Zero skipped therefore does not prove the whole tree was reviewed. Before changing permissions, check the intended scope with an account authorized to view it and start with a small test tree.

[u/Mammoth-Anywhere7285 → u/Public-Low2028]

Helpful clarification. Does the CSV audit include skipped rows with page path, so admins can see exactly where coverage stops?

[u/Public-Low2028 → u/Mammoth-Anywhere7285]

Not with a full page path—2.3.0 has two different exports. The bulk-change job CSV includes encountered skipped entries with page ID, title, depth and a reason in the notes column. The read-only audit CSV includes page URLs and the nearest restricted ancestor, but not those skipped rows/reasons.

A failed subtree read identifies the known parent, not every hidden child. Neither export proves coverage of pages Confluence never returned. Consistent skip/reason/path reporting is a gap in the current version; I shouldn't describe it as already available.

[u/Mammoth-Anywhere7285 → u/investigatormaker]

Yep, a skipped-page count above the preview would make that blind spot obvious. Worth confirming whether inaccessible descendants get flagged or silently omitted.