From b400ad580a37a401136e8ea5d29393e0b2bda545 Mon Sep 17 00:00:00 2001 From: zemion Date: Mon, 6 Jul 2026 14:34:08 +0200 Subject: [PATCH] Sync Repo-docs-SYSTEM-GOVERNANCE-MANIFEST from project files --- Repo-docs-SYSTEM-GOVERNANCE-MANIFEST.-.md | 186 ++++++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 Repo-docs-SYSTEM-GOVERNANCE-MANIFEST.-.md diff --git a/Repo-docs-SYSTEM-GOVERNANCE-MANIFEST.-.md b/Repo-docs-SYSTEM-GOVERNANCE-MANIFEST.-.md new file mode 100644 index 0000000..94bc982 --- /dev/null +++ b/Repo-docs-SYSTEM-GOVERNANCE-MANIFEST.-.md @@ -0,0 +1,186 @@ + + +> Mirrored from `/mnt/DATA/git/govoplan-core/docs/SYSTEM_GOVERNANCE_MANIFEST.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# Multi Seal Mail - Current System and Tenant Governance Model + +**Updated:** 2026-06-16 +**Current migration head:** `f5a6b7c8d9e0` + +## Governance Rule + +System policy is authoritative for tenants and all lower levels. Each lower level may only narrow what it inherits: + +```text +system +-> tenant +-> user or group owner +-> campaign +``` + +Lower levels do not widen privileges, allowed profiles, retention durations or credential rights granted by a higher level. + +## Administration Structure + +```text +SYSTEM +- Settings +- Retention +- Mail servers +- Tenants +- Users +- Groups +- System roles +- Tenant roles +- Audit + +TENANT +- Settings boundary +- Users +- Groups +- Roles +- API keys +- Mail servers +- Retention +- Audit + +USER +- User mail +- User retention + +GROUP +- Group mail +- Group retention +``` + +There is no separate System access page. Compatibility access scopes remain in the backend for assignment/read boundaries. + +## Tenant Governance + +System settings define tenant defaults and whether tenants may narrow selected options. Tenant overrides can only restrict: + +- custom groups; +- custom roles; +- tenant API keys. + +The backend enforces that tenant governance cannot widen system-denied privileges. + +## Mail-Profile Governance + +Mail server profiles may exist at these scopes: + +```text +system +tenant +user +group +campaign +``` + +Effective campaign profile availability follows campaign ownership. A campaign owned by a user resolves through system, tenant, that user and campaign policy. A group-owned campaign resolves through system, tenant, that group and campaign policy. + +Policy semantics: + +- higher levels define the maximum available profile set; +- lower levels can further restrict the set; +- forced profiles mean the lower level must choose from the forced set; +- a forced set with one profile effectively enforces that profile; +- campaign-level profile creation is allowed only if the effective policy permits it; +- SMTP/IMAP credentials use one inheritance decision per protocol: lower levels must inherit profile credentials, may inherit profile credentials, or must provide local credentials; +- the lower-level override switch for `smtp_credentials.inherit` and `imap_credentials.inherit` controls whether descendants may change that inheritance decision; +- deny patterns always win over allow patterns; +- empty or `*` allowlist means allow all except denied; +- non-empty allowlist means at least one allow rule must match and no deny rule may match. + +Pattern targets: + +```text +SMTP hostname +IMAP hostname +envelope sender +From header +recipient domains +``` + +Ownership transfer is intentionally deferred as a two-step workflow: original owner initiates, new owner accepts and reselects/repairs the mail profile if their effective policy requires it. + +## Retention Governance + +Retention policy is hierarchical: + +```text +system -> tenant -> user/group -> campaign +``` + +Managed fields: + +- raw campaign JSON retention days; +- generated EML retention days; +- stored report detail retention days; +- mock mailbox retention days; +- audit detail retention days. + +Rules: + +- system may set concrete defaults or unlimited retention; +- system exposes allow-limiting toggles per field; +- tenants, users/groups and campaigns may only shorten inherited retention where the parent allows limiting; +- blank lower-level values inherit; +- mock mailbox retention is currently system-level because mock mailbox records do not yet carry tenant/campaign ownership metadata; +- dry-run/apply retention actions report affected classes before destructive cleanup. + +## Role Definitions and Assignments + +### System roles + +System roles define instance-wide permissions. `system:*` is stored as one wildcard and displayed as granting the full system catalogue. System owner is protected. + +### Tenant roles + +Tenant roles can be system-governed templates or tenant-local definitions, subject to system tenant-governance settings and actor delegation ceilings. Wildcard counts are expanded against the canonical tenant catalogue. + +## Audit Access + +Audit access remains scope-separated: + +```text +system audit -> system:audit:read +tenant audit -> active tenant + audit:read +``` + +Audit pages use server pagination, filtering and bounded grids. + +## Tenant Switching + +Tenant switching preserves the current URL when possible and falls back when a route/resource is not accessible in the new tenant context. + +The tenant selector is hidden for ordinary single-tenant accounts and visible for multi-tenant or system tenant-management contexts. + +## DataGrid Contract in Administration + +Admin lists use bounded container grids: + +- one flexible fill column; +- fixed total table width; +- compact action/status/count columns; +- resizable text/date columns; +- no intrinsic content growth; +- sticky headers where needed; +- server pagination for audit. + +## Still Deferred + +- real SMTP/IMAP test-bed verification and operator runbook; +- recipient import with column mapping; +- Seafile/external connector governance; +- system/tenant/group/user file-space hierarchy and external storage hierarchy; +- session/device revocation UI; +- backup/restore, monitoring and update procedures; +- DSAR workflows and evidence bundle verifier; +- campaign ownership transfer workflow; +- policy impact analysis before delete/disable/unshare/change; +- LDAP/OIDC/SAML provisioning; +- destructive tenant erasure orchestration.