Summary

Ability to configure more granular custom roles in Confluence RBAC by relaxing the current permission dependencies, so that legacy space permission combinations can be reproduced as roles

Description

In the current Confluence Cloud RBAC implementation, custom roles are constrained by strict permission dependencies.

When an admin creates or edits a custom role, enabling a single “higher‑level” permission (for example, “Manage user access to space” or “Manage space and space settings”) automatically enables a large set of related permissions (create, edit, delete, archive content, comments, attachments, exports, etc.).

This behaviour is documented in the RBAC help page as “permissions dependencies”, and it is intended to:

• prevent inconsistent or invalid permission combinations, and  
• avoid access escalation issues.

However, for some customers who previously relied on the legacy space permission table, this design makes it impossible to reproduce certain very specific, minimal “sub‑set” permission combinations as custom roles.

A concrete example from our customer:

• In the legacy space permissions grid, they have a group that is configured as follows:
    - “View all” = ON  
    - “Add / remove restrictions” = ON  
    - “Space admin” = ON  
    - All other permissions (create/edit pages, blog posts, comments, attachments, delete, archive, export, etc.) = OFF
• This combination is used as a support role:  
    - users can see everything, manage restrictions, and perform some admin tasks,  
    - but they must not be able to create/edit/delete regular content.

In the new RBAC custom roles UI, when they try to create an equivalent role:

• Turning on a single permission such as “Manage user access to space” or “Manage space and space settings” causes many other permissions to be auto‑enabled (create, edit, delete, archive, export, attachments, comments, etc.).
• As a result, the admin cannot create a custom role that matches the legacy “minimal admin” sub‑set.  
    They either have to:
    - grant more permissions than before (e.g., allow content editing/deletion), or  
    - give up on that role design.

This is blocking some customers from cleanly migrating their existing space permission model to RBAC, because the old combinations are not expressible under the current dependency rules.

Suggested features

Customers are asking for more flexible permission configuration in RBAC custom roles, specifically:

• Relax the current permission dependencies in custom roles so that:
    - enabling one permission does not automatically enable an entire set of additional permissions, except where absolutely necessary (for example, “View content” as a base).
    - admins can choose more precisely which permissions to include or exclude.