Permission inheritance and impact preview for Confluence Cloud. An Atlassian Forge app that applies a page's restrictions to everything below it — after showing you, page by page, who will lose access and who will keep it.
Confluence has no page permission inheritance. Restricting a parent page hides its children, but every other restriction has to be set page by page. Atlassian has said it will not add inheritance, and gave the reason: no design passed their bar for letting people "quickly and easily make decisions and understand the impact of them".
Leafward is that missing impact preview, with the inheritance attached to it.
- Impact preview before anything is written. Point Leafward at a page, and it reads the whole subtree in one pass, then states the consequences as sentences: who gains access, who loses it, which branches are left alone. Nothing is written until you have read it.
- A subtree is rarely only pages. Whiteboards, databases and folders sit inside it and carry their own restrictions, and a cascade that quietly skipped them would leave the one thing nobody thinks to check still open. Leafward reads them, counts them beside the pages, names them for what they are, and applies to them — and where it runs out of room to read some, it says how many rather than letting the count imply there were none. Automatic inheritance covers them too, which is what the View whiteboards, View databases and View folders permissions are for on the install screen: Confluence tells an app that a whiteboard was created without saying where, so Leafward has to ask. They are read permissions and nothing else — Leafward still writes nothing but restrictions.
- Export the plan for approval. A subtree change usually needs a sign-off from someone who will never open the app. The plan is a document before it is an action.
- Exclude pages before the run. A page ticked out shields its own subtree, exactly as a page left alone does.
- Undo. A run records what each page held before it, so reverting restores only the pages that run touched.
- A permission report that filters and exports, including the finding that a page can be correctly hidden while nothing restricts editing it — Confluence propagates a read restriction down the tree and does not propagate an update one, and shows the same padlock for both.
- An access review that states what it could not see, space by space — and answers "what changed since the last one" against a remembered baseline.
- Orphaned restrictions: restrictions naming accounts that no longer exist, and the sequel — removing one account or group from every restriction that names it.
- Space permissions: read, preview, grant, change and remove.
Install Leafward from the Atlassian Marketplace. There is nothing to configure afterwards — no account to create, no key to paste, no service to connect.
Check that the app can reach what it needs. Open Leafward from the Confluence app menu, go to the Coverage tab and press Run self-check. It asks your own site, from inside the app, whether each endpoint Leafward depends on answers. This matters because an endpoint that answers a person's browser can refuse an app, so nothing outside your site can tell you what your site allows. A screenshot of that panel also answers most support questions before they are asked.
Cascade a page's restrictions. Open the page whose restrictions you want to push down, then ••• → Leafward — inherit permissions. Leafward reads the whole subtree and shows, page by page, what would change and who would lose access. Nothing is written yet. Untick any page or branch you want left alone — an excluded page shields everything beneath it — export the plan as a CSV if it needs approval, then apply. The run is resumable, keeps a journal line per page, and can be undone.
See why one page is visible to whom. Under any page title there is a Leafward byline item. It lists every restriction between that page and the top of the tree, nearest first, and says when a padlock covers reading only while anyone allowed in can still edit.
Report, review and compare. The Leafward global page holds four tabs: Coverage (what the app can and cannot see, space by space), Permissions (every restriction, filterable and exportable), Runs (what was applied, and undo), and Automatic inheritance (opt in, per space, so newly created or moved pages take their parent's restrictions).
Who can do what. Leafward asks whether you administer the space, not whether you can restrict the page. That is stricter than Confluence's own rule and deliberately so: it will refuse some people who could restrict a page by hand.
- Privacy — what Leafward stores, what it never touches, and why the list of sub-processors is empty.
- Support — how to get help, the built-in self-check, and the behaviours that look like defects and are not.
Two things worth knowing before a security review:
Leafward declares no egress permissions. A Forge app can only reach the internet if its manifest says so, and Leafward's does not. There is no server of ours for your data to travel to.
Leafward stores no display names. Account identifiers only, resolved from your directory at the moment a screen shows them. That is Atlassian's own recommendation, and it removes the personal-data reporting obligation rather than servicing it.
Leafward is sold on the Atlassian Marketplace. Free for up to 10 users. There is a page describing it at growingpeas.dev/leafward, with screenshots.
This repository holds the project description and the public documents only — the application source is private.