Roles & Permissions

Fine-grained access control: module capabilities, per-node-type ACLs, and event subscriptions.

Two axes of access

Manage at /admin/roles. Roles control access along two independent axes:

  • Module capabilities — which admin sections this role can see and operate
  • Node access control — which content this role can read or write, defaulted per node-type with per-node overrides

Plus a third axis bolted on for convenience: email subscriptions for lifecycle events.

Module capabilities

Toggles per role for each core admin module:

  • Admin access — can the user enter /admin/* at all
  • Manage users
  • Manage roles
  • Manage settings
  • Manage menus
  • Manage media
  • Manage taxonomies
  • Manage themes
  • Manage extensions
  • Manage layouts & partials
  • Manage content blocks
  • Manage emails (layouts, templates, providers, rules, logs)
  • Manage forms
  • View audit log

Capabilities are checked at every admin endpoint and at every CoreAPI call. There is no override — even superadmins are evaluated.

Node access control

Default level per node type

Per role, set a default access level for each registered node type:

  • none — invisible to this role
  • read — can list and view, can't edit
  • write — full CRUD on nodes of this type

Example: an Editor role might be write on blog_post, read on page, none on internal_doc.

Per-node overrides

Open any node and use the Permissions sidebar panel (visible to roles with Manage roles). Add an explicit allow/deny entry for any role on this specific node — useful when a single draft needs to be reviewed by a wider group than the type-level default permits.

TIP
Common pattern: a Translator role gets read on every node type, and per-node write overrides only on the translation rows they're assigned. The default is safe; the override is targeted.

Email subscriptions per role

Each role declares which lifecycle events its members get emailed about. The email-manager rules engine reads these subscriptions to decide who to send to when a rule's recipients are set to from-role-subscription.

Subscribable entities

  • Block type — create / update / delete
  • Layout + layout block — create / update / delete
  • Menu — create / update / delete
  • Node — create / update / delete, filterable per node type
  • User — create / update / delete

Per-event verb selection

For each entity, subscribe to one verb (create only), several (create + delete), or all. Multi-verb selections are rendered as comma-separated chips in the role editor.

Multi-role users

Users can hold multiple roles. Capabilities are unioned across all assigned roles — if any role grants the cap, the user has it. Node access uses the most-permissive level across roles.

Built-in roles

Out of the box: Administrator (everything), Editor (content modules + write on standard node types), Author (write only on their own nodes), Subscriber (no admin access). Built-in roles are editable; you can also create your own.

NOTE
Capability checks live at the kernel level — not just the React admin. Hitting an admin REST endpoint directly without the right cap returns 403, even from MCP. The same guard applies to CoreAPI calls from extensions and Tengo scripts.