Roles & permissions

The Roles & permissions screen manages local access control (RBAC) — who may do what. It separates duties across the supply chain (requester, approver, buyer, receiver) so it is auditable, as Part-145 requires. It is an interim solution, to be replaced by Keycloak.

Roles and permissions

A permission is an elementary right (“approve a purchase request”). A role groups permissions and is assigned to users. A user may hold several roles.

  • System roles — the four supply roles (Requester, Approver, Buyer, Receiver) are created automatically and are read-only: they cannot be edited or deleted.
  • Custom roles — create your own as needed, with the subset of permissions you want. The code (technical identifier) is fixed after creation; name and permissions stay editable.

The table shows, for each role, its permissions and the number of users holding it.

Assigning a role to a user

Assignment happens on the User accounts screen: a row’s Roles button opens the list of roles, where checking/unchecking assigns or removes it immediately (each action is logged to the sealed audit).

How it is enforced

  • The Administrator account role remains a super-user: it passes every check.
  • Two hard business rules of the purchasing chain are enforced server-side, regardless of roles: the approver cannot be the requester, and an approval threshold by amount (coming with orders).
  • Effective permission enforcement arrives with the engagement chain (purchase request → order); roles can be defined and assigned now to prepare the ground.

See also