20 lines
1.7 KiB
Markdown
20 lines
1.7 KiB
Markdown
# Policy Interface Pattern Migration
|
|
|
|
Policy contributes four retention-administration sections to the Access-owned
|
|
administration host. It does not own an independent route or shell.
|
|
|
|
| Surface | Archetype | Consequence and provenance | Evidence |
|
|
| --- | --- | --- | --- |
|
|
| System retention | Effective-policy editor plus destructive operation | Typed values show their effective source path. Applying retention can irreversibly redact or delete eligible content and therefore requires explicit confirmation; dry-run and applied outcomes are distinguished. | `RetentionPoliciesPanel.tsx`, Core `RetentionPolicyScopeManager`, interface-pattern structural test |
|
|
| Tenant retention | Effective-policy editor | A tenant may only narrow fields that system policy allows. Read-only authority and parent locks are explicit. | Core policy-source and blocker components |
|
|
| Group retention | Targeted effective-policy editor | Group selection is loaded through bounded delta requests; missing target, parent lock, and write authority remain distinct states. | Target loader plus Core retention editor |
|
|
| User retention | Targeted effective-policy editor | User labels expose only authorized account metadata; retained data itself is never returned by this administration surface. | Target loader plus Core retention editor |
|
|
|
|
The retention execution result is a typed, filterable outcome table. Raw JSON
|
|
is neither the primary policy editor nor the operator result view. The backend
|
|
remains authoritative for policy validation, narrowing rules, destructive
|
|
effects, redaction, and audit evidence.
|
|
|
|
Contextual help uses `policy.retention` and `privacy.retention`, which resolve
|
|
through the optional Docs module or the hosted documentation fallback.
|