-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Permissions - Space
-
None
-
1
With the new RBAC model, many customers want a support / IT / admin‑helper role that can:
- See content in a space
- Manage who has access to the space (via roles)
- View space‑level insights like Analytics
…but cannot:
- Export content (space export, page‑by‑page export, or API/scripted export)
- Delete any content (their own or others’)
This is a very common pattern for IT support, helpdesk, or delegated admin teams who should help with access issues, but must not have data‑exfiltration or destructive powers.
What’s hard today
Right now, permissions like:
- Manage access to space
- Export individual content / Export space
- Delete own content / Delete anyone’s content
are not cleanly separable for this use case. It’s difficult to give someone access‑management and Analytics without also giving them some level of export or delete capability, especially if you consider scriptable/API exports.
While this general ask is already covered in https://jira.atlassian.com/browse/CONFCLOUD-83247, we’re specifically looking for the ability to define a role with the following shape:
- ✅ View content
- ✅ Manage access to space
- ✅ View Analytics
- ❌ No export (of any kind)
- ❌ No delete (pages, blogs, attachments, comments)
Nice to have – built‑in template
For larger and regulated customers, there is often a strict separation between:
- Who can manage access
- Who can export or delete data
A clean “access‑only” role (or even a built‑in template, e.g. “Access Support” / “IT Support – access only”) would:
- Help meet internal security and audit requirements
- Let customers safely delegate access troubleshooting to IT/helpdesk teams
- Enable RBAC adoption without recreating an “all‑powerful space admin” risk profile
Current workaround
- Data Security Policies → Block export can be used at the org level to stop exports (including API/scripted exports) for selected scopes, regardless of role.
- This does help with export risk, but:
-
- It’s not role‑aware (it applies to everyone in scope), and
-
- It doesn’t address delete permissions.