59 lines
3.2 KiB
Markdown
59 lines
3.2 KiB
Markdown
# GovOPlaN Policy
|
|
|
|
<!-- govoplan-repository-type:start -->
|
|
**Repository type:** module (platform).
|
|
<!-- govoplan-repository-type:end -->
|
|
|
|
`govoplan-policy` owns policy and retention API route contributions and the
|
|
retention administration WebUI sections during the GovOPlaN module split.
|
|
|
|
The `@govoplan/policy-webui` package contributes system, tenant, group, and
|
|
user retention sections through the shared `admin.sections` UI capability. The
|
|
admin shell does not render retention policy panels unless this module is
|
|
installed and enabled.
|
|
|
|
The same administration contribution exposes hierarchical **View policy** at
|
|
system, tenant, group, and user scope. Administrators can inherit, allow, or
|
|
block View use, selection, assignment, editing, derivation, and workflow
|
|
activation. Optional View-ID and surface-ID ceilings are intersected across the
|
|
scope path, and the UI displays effective limits and provenance. Lower scopes
|
|
can narrow but never broaden an ancestor restriction.
|
|
|
|
Policy decision and provenance payloads use the shared kernel DTOs documented
|
|
in [docs/POLICY_DECISION_PROVENANCE.md](docs/POLICY_DECISION_PROVENANCE.md)
|
|
and `/mnt/DATA/git/govoplan-core/docs/POLICY_CONTRACTS.md`.
|
|
|
|
Hierarchical policy evaluation, delegation ceilings, and write simulations are
|
|
implemented in `govoplan_policy.backend.hierarchy`. Privacy retention uses that
|
|
shared helper and exposes `/api/v1/admin/privacy-retention/policies/{scope}/simulate`
|
|
for preflight checks before saving lower-level policy changes.
|
|
|
|
The module also provides the optional
|
|
`policy.schedulingParticipantPrivacy` capability. Scheduling owns each
|
|
request's participant-visibility setting; Policy can only preserve or narrow
|
|
it. The resolver reads an optional `maximum_visibility` ceiling from the
|
|
`scheduling_participant_privacy_policy` object in system and tenant settings.
|
|
Missing policy is unrestricted, while malformed explicit policy fails closed
|
|
to aggregate-only visibility. This resolver slice intentionally has no policy
|
|
management endpoint or UI yet.
|
|
|
|
Policy also provides `policy.definitionGovernance` for Dataflow and Workflow
|
|
libraries. It evaluates view, edit, run/start, reuse, derive, and automation
|
|
actions across system, tenant, group, and user scopes. Templates cannot run or
|
|
be automated. Derived definitions retain ancestor ceilings, and every
|
|
decision includes the ordered Policy source path and effective limits so a UI
|
|
can explain why an action is available or blocked.
|
|
|
|
Cross-module reports use `policy.reporting_governance`. System policy defines
|
|
the export, retention, privacy-transform, and high re-identification-risk
|
|
ceiling; tenant policy may only tighten it, and malformed explicit policy fails
|
|
closed. The shared privacy-retention run calls the optional
|
|
`reporting.retention` capability to clear expired provider-report payloads
|
|
without importing Reporting models, while Reporting keeps hashes and bounded
|
|
provenance as audit evidence.
|
|
|
|
The retention administration interface follows the platform pattern language
|
|
documented in [docs/INTERFACE_PATTERN_MIGRATION.md](docs/INTERFACE_PATTERN_MIGRATION.md).
|
|
It uses Core's effective-policy editor and renders system retention runs as
|
|
typed outcome evidence rather than raw JSON.
|