Add the compliance permission and the Compliance Officer roles #88

Merged
jcoffey-dev merged 2 commits from feature/compliance-roles into main 2026-09-28 16:34:17 +00:00
Owner

Personal-data catalog §7, Phase 3b.

  • sysComplianceGet (673): superusers and tenant admins (their slice); granted once to stored admin roles.
  • Server-level Compliance Officer: audit read/export, legal holds (place/widen/release/export), locks read, directory reads. No settings.
  • Per-tenant Compliance Officer (MT-3 needs same-tenant roles): created for existing tenants and on tenant creation; removed with an unused tenant so deletes still work.
  • Both include a user's own permissions (they replace the default user role).
  • Spec §7 records the per-tenant change.

Tested: unit tests; new compliance system test; system, audit, legal hold, account lock, SCIM suites; fork checks. Directory suite not run (needs LDAP container).

Personal-data catalog §7, Phase 3b. - `sysComplianceGet` (673): superusers and tenant admins (their slice); granted once to stored admin roles. - Server-level Compliance Officer: audit read/export, legal holds (place/widen/release/export), locks read, directory reads. No settings. - Per-tenant Compliance Officer (MT-3 needs same-tenant roles): created for existing tenants and on tenant creation; removed with an unused tenant so deletes still work. - Both include a user's own permissions (they replace the default user role). - Spec §7 records the per-tenant change. Tested: unit tests; new compliance system test; system, audit, legal hold, account lock, SCIM suites; fork checks. Directory suite not run (needs LDAP container).
jcoffey-dev added 1 commit 2026-09-28 15:50:22 +00:00
Add the compliance permission and the Compliance Officer roles
ci / fork-checks (pull_request) Successful in 31s
ci / build (pull_request) Successful in 11m31s
63adb4e2b8
Personal-data catalog spec, §7 (settled 2026-09-28).

sysComplianceGet (673) sees the data inventory and compliance
overview: superusers and, for their tenant's slice, tenant
administrators, by default and through the one-time grants on servers
that already have their roles stored.

A Compliance Officer role at server level holds it with reading and
exporting the audit log, placing, widening, releasing and exporting
legal holds, seeing account locks, and reading accounts, lists,
domains, tenants and roles. It changes no server setting, creates or
deletes no account, and can't shorten audit retention.

A tenant's accounts can hold only roles of their own tenant (MT-3), so
the tenant role is one "Compliance Officer" role per tenant, without
holds (LH-13): made once for every tenant a server has, and whenever a
tenant is created. While nobody holds it, it is removed with its tenant
so it doesn't block the delete, and put back if the delete is refused
for another reason. Both roles carry a user's own permissions too,
since roles given to a person replace the default user role, which a
tenant's accounts can't hold anyway.

Every server makes these once, new or existing -- the built-in roles
are only made on a server with none -- and records each under P c, so a
role an administrator deletes stays deleted.

Tested: unit tests (neither role changes a setting beyond a user's
own; holds for the server's officer only; per-place records); a new
compliance system test (one server-level role; an officer reads the
audit log, places and releases a hold, and is refused a setting, an
account and audit retention; a tenant gets its role, whose holder reads
the tenant's audit log and no holds; a tenant with an unused role is
deleted and the role goes with it); the system, audit, legal hold,
account lock and SCIM suites; fork checks. The directory suite needs
its LDAP container and wasn't run here.
jcoffey-dev added 1 commit 2026-09-28 16:26:31 +00:00
Merge main (upstream v0.16.24) into feature/compliance-roles
ci / fork-checks (pull_request) Successful in 15s
ci / build (pull_request) Successful in 7m33s
7285b3e38a
The schema conflicted as a binary file: taken from main and the one
edit here re-applied (sysComplianceGet after sysLegalHoldExport). The
import kept the permission count at 673, so the new id stays 673.

Retested on the merged tree in its own target directory: the
compliance and system suites pass. One earlier system run failed in
purge.rs (an imported blob not found) and didn't recur.
jcoffey-dev merged commit c61497e2b2 into main 2026-09-28 16:34:17 +00:00
jcoffey-dev deleted branch feature/compliance-roles 2026-09-28 16:34:18 +00:00
jcoffey-dev referenced this issue from a commit 2026-09-28 19:22:38 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#88