Business module
Roles & Permissions Management
Permission tiers your organisation defines and assigns — who may do what, decided per product, enforced everywhere, and recorded on the audit trail.
Access control fails in two directions: people who can't do their jobs, and permissions nobody remembers granting. Kellith's answer is a module where “what can this person do?” always has exactly one answer, and no change to it can go unrecorded.
The rules it enforces
Not aspirations — guarantees. Each of these is a documented behaviour of the module, covered by a test.
- A person holds exactly one tier.
- Assigning a tier replaces the old one; permissions never accumulate by accident. The audit question has one answer.
- A new tier starts with nothing implied.
- It holds exactly what it was given. Starting from a copy of an existing tier is how over-granting happens, so there is no copy.
- A tier cannot be deleted while people hold it.
- The refusal says how many. Nobody's access is stripped as a side effect of tidying a list.
- No change can leave the organisation without a role manager.
- Editing management out of the last managing tier, or reassigning its last holder, is refused. Locking everyone out is the one mistake the module will not let an admin make.
- An unrecorded permission change cannot happen.
- Access is the one module where a failed audit write blocks the operation itself — because the trail is the control that watches the controllers.
- A change takes effect on the very next question.
- There is no propagation delay to reason about: grant it, and the next check honours it.
What it lets people do
- See the roles this product offers and who holds each one.
- Define the organization's roles and decide who holds each one. Every change is recorded on the audit trail, and no change can leave the organization without a role manager.
Runs inside
Need access in a product shaped for you? Tell us what to assemble.