Software Requirements: Administration, Permissions & Onboarding¶
Introduced in requirements baseline v1.1 (GAP-03, ADR-0012).
| ID | Requirement | Trace |
|---|---|---|
| REQ-ADM-001 | The system shall define a fixed, closed set of named permissions covering content/functional and administrative capabilities. | STR-017; ADR-0012 |
| REQ-ADM-002 | Each catalog role shall be configurably associated with a set of permissions; changing the mapping shall require the MANAGE_CATALOG permission. |
STR-006, STR-017; ADR-0012, ADR-0004 |
| REQ-ADM-003 | Holding a role in a scope shall grant that role's permissions within the scope and its descendant scopes; a role held at the global scope shall grant them installation-wide. | STR-017; ADR-0012 |
| REQ-ADM-004 | Administrative and content permissions shall be independent; system-administration permissions shall not implicitly grant content read access, preserving mandator separation. | STR-003, STR-017; ADR-0012 |
| REQ-ADM-005 | Document life-cycle transitions shall remain governed by review policies (ADR-0003); the permission model shall govern all other functional and administrative actions. | STR-002, STR-017; ADR-0012, ADR-0003 |
| REQ-ADM-006 | A deployment-configured bootstrap identity shall be granted system administration idempotently on startup (initial setup and break-glass recovery); the system shall not permit removing the last administrative capability and leaving none. | STR-017; ADR-0012 |
| REQ-ADM-007 | On first initialization the system shall create the global base scope and an internal mandator with a QMS-operations scope. | STR-015, STR-017; ADR-0012, ADR-0010 |
| REQ-ADM-008 | Onboarding a project/scope shall consist of creating the scope, activating the required catalog roles and document types, staffing roles, and configuring review policies — each gated by the corresponding permission. | STR-006, STR-017; ADR-0012, ADR-0004, ADR-0003 |
| REQ-ADM-009 | All administrative actions (scope/mandator/user/catalog/policy changes and role assignments) shall produce audit events. | STR-009, STR-017; ADR-0012, REQ-AUD-001 |
| REQ-ADM-010 | The oversight/traceability views shall be governed by two scope permissions added to the fixed permission set (REQ-ADM-001): VIEW_TRACEABILITY (the engineering-trace views — requirement coverage, risk traceability, document relations, later validation/GSPR) and VIEW_TRAINING_COMPLIANCE (the personal-data-sensitive training-compliance oversight). Each shall be ENFORCED SERVER-SIDE at the view's data endpoint — not merely reflected in the UI (a hidden tile is not access control) — and shall be scope-aware (a view is reachable only for the scopes where the caller holds its permission). The vocabulary migration and demo seed shall BACKFILL VIEW_TRACEABILITY to all scope members (preserving today's reach; RLS continues to scope the data) and grant VIEW_TRAINING_COMPLIANCE to the QMB / quality-manager role only, deliberately tightening the currently-open training oversight. |
STR-003, STR-011, STR-027; ADR-0080, ADR-0012 |
| REQ-ADM-011 | A freshly installed system shall be fully operable from its bootstrap administrator without out-of-band data manipulation: administrative surfaces reflect assignment-held authority, audited acts succeed wherever the actor is staffed or belongs, and every guided path is walkable to its end. | STR-017; ADR-0106, ADR-0107, ADR-0108 |
| REQ-ADM-012 | The system shall provide an admin System page whose sections render per their own gates: the backup act + evidence (EXPORT_BACKUP; REQ-BAK-006/007) and a maintenance section (MANAGE_SYSTEM_SETTINGS) surfacing the audited search-reindex act and read-only background-job heartbeats (each sweep stamps its last run; a job that never ran shows honestly as such). (ADR-0116 §5; heartbeats via the V102 system_job_heartbeat stamps.) |
STR-010, STR-015; ADR-0116 |