Saltar a contenido

Permissions & Roles

Turbo EA uses a three-layer permission model that combines application-wide role-based access control with card-specific stakeholder roles. This page explains the design, when to use each layer, and how the layers combine into effective permissions.

Why three layers?

Enterprise Architecture is inherently cross-functional. A given card — say, an Application — might be:

  • Read-only for most users (viewers see the inventory but cannot edit)
  • Editable by the general EA team (members can update any card)
  • Managed by a specific person responsible for that application (the Technical Application Owner can edit and approve status, even if they don't have organisation-wide edit rights)
  • Fully controlled by admins (who can do anything)

A flat role system handles the first three cases but breaks the fourth: you either give someone organisation-wide edit rights (too broad) or nothing (too restrictive). The stakeholder layer solves this by granting per-card permissions to named individuals.

Layer 1 — Application roles

Application roles are assigned to users and apply across the entire platform. They are defined and managed in Admin → Users & Roles.

Each role carries a JSON permission set. The built-in roles are:

Role Key Scope
Admin admin Wildcard {"*": true} — unrestricted
BPM Admin bpm_admin Full BPM + full inventory, no admin.*
Member member Full inventory + BPM edit, no admin.*
Viewer viewer View-only across all domains

Custom roles can be created with any combination of the 69 available permission keys, grouped into domains like inventory.*, reports.*, bpm.*, ppm.*, grc.*, admin.*.

Use application roles when you need to control what a class of users can do across the whole platform.

Layer 2 — Stakeholder roles

Stakeholder roles are assigned to users on specific cards. Each card type defines its own set of stakeholder role definitions (e.g. Application cards have "Technical Application Owner", "Business Application Owner", "Data Steward"). These are configured in Admin → Metamodel → [type] → Stakeholder Roles.

Each stakeholder role definition carries a set of card-level permissions — things like card.edit, card.approve, card.manage_relations. When a user is added as a stakeholder on a card, they gain those permissions on that card only.

Use stakeholder roles when ownership or accountability is card-specific: the owner of a particular application should be able to manage it without getting edit rights on all 500 other applications.

Layer 3 — Effective permissions

When a user attempts an action on a card, the system computes their effective permissions by combining:

  1. Their application-role permissions (mapped from platform-level to card-level keys)
  2. All stakeholder role permissions they hold on that specific card

The result is the union of both sets. A user who is a Viewer (platform-wide) but a Technical Application Owner on one card can edit that card, because the stakeholder role grants card.edit even though the Viewer role does not.

The effective permissions for the current user on a given card are exposed at GET /cards/{id}/effective-permissions and drive all edit/approve/delete controls in the UI.

The admin wildcard

The Admin role uses {"*": true} as its permission set. This is evaluated as "allow everything" — including permissions that did not exist when the role was created. This means new modules and new permission keys are automatically available to admins without any role update.

No other built-in role uses the wildcard. When creating custom roles, use explicit permission keys rather than wildcards — this makes the role's scope auditable and prevents accidental over-granting.

Permission key structure

All permission keys follow a domain.action pattern:

  • inventory.view — read cards
  • inventory.edit — update cards
  • inventory.create — create cards
  • admin.metamodel — manage card types and relation types
  • bpm.approve — approve BPMN process flow versions
  • risks.manage — create and update risk register entries

The complete list of valid keys is in backend/app/core/permissions.py, which is the single source of truth. New permission keys must be added there before they can be granted to any role.

Common patterns

Restrict a module to a team: Create a custom role with only the ppm.* and inventory.view permissions. Assign it to the project portfolio team. They can work in PPM but cannot edit the main inventory.

Grant approval rights without edit rights: Give a business stakeholder the "Business Application Owner" stakeholder role on specific Application cards. Configure that role to include card.approval_status but not card.edit. They can approve cards that the EA team has populated, but cannot change the data.

Break glass for an admin: The admin wildcard means any future permission — including permissions added by extensions or future versions — is automatically granted. Use the Admin role only for users who genuinely need unrestricted access.

See also