Story: Roles and permissions
Table of Contents
This page documents a story in Sprint 07. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Introduce role-based access control (RBAC) end-to-end: domain types, enforcement at the handler layer, and a Qt UI for management.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 07 |
| Now | Completed 2025-12-28. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2025-12-28 |
Acceptance
- RBAC primitives — roles, permissions, role-permission, user-role — present and tested.
- Handlers reject requests the caller is not permitted to make.
- Qt UI covers role and permission management end-to-end.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Add core infrastructure for roles and permissions | DONE | 2026-05-19 | 2025-12-26 | Domain model (role, permission, role-permission, user-role), repositories, sqlgen schemas. |
| Implement RBAC enforcement | DONE | 2026-05-19 | 2025-12-27 | Enforce role-based access at the message handler layer: reject requests the calling session lacks permission for. |
| Add UI for roles and permission management | DONE | 2026-05-19 | 2025-12-28 | Qt UI for listing roles, listing permissions, assigning roles to users, and granting permissions to roles. |
Decisions
- Permission required is per-handler
- declared on the handler itself so the access surface is greppable.
- Type-traits-driven dispatch
- lets the RBAC enforcement code read the required permission from the message trait rather than open-coding a switch.
Out of scope
- Attribute-based access control (ABAC); RBAC is the right starting shape.
- Per-row authorisation; this story is about API-surface authorisation.
See also
- ores.iam — the component that owns the RBAC domain types.
- Comms features — the sibling story whose type-traits refactor underpins RBAC enforcement.