67 lines
3.5 KiB
Markdown
67 lines
3.5 KiB
Markdown
# govoplan-cases
|
|
|
|
<!-- govoplan-repository-type:start -->
|
|
**Repository type:** module (domain).
|
|
<!-- govoplan-repository-type:end -->
|
|
|
|
`govoplan-cases` owns formal administrative case context for GovOPlaN.
|
|
|
|
The module should stay focused on case identity, lifecycle state, assignments,
|
|
deadlines, participants, evidence links, and case-level audit context. It should
|
|
not own forms, files, workflow execution, task queues, templates, payments, or
|
|
mail delivery; those are integrated through GovOPlaN capabilities, events,
|
|
commands, and DTOs.
|
|
|
|
The executable backend slice now exposes:
|
|
|
|
- `cases.service_intake`, which converts one published, effective Service
|
|
definition into a case intake plan while retaining the exact service,
|
|
mandate, jurisdiction, legal-basis, form, workflow, result, evidence, and
|
|
deadline references; and
|
|
- `cases.party_context`, which consumes an optional procedure-party provider
|
|
or a bounded Cases-only compatibility projection and emits policy-filtered,
|
|
frozen contact snapshot references for downstream delivery; and
|
|
- `cases.registry` plus `/api/v1/cases`, which persist tenant-local case/status
|
|
catalogs, stable case identities, immutable OCC-guarded revisions, stable
|
|
assignment/evidence/Decision/record references, and replay-safe lifecycle
|
|
events; and
|
|
- `cases.service_launcher`, which opens exactly one deterministic case from an
|
|
exact published Service revision and safely replays the same Portal launch;
|
|
and
|
|
- `tickets.case_escalation`, which creates exactly one formal Case from an
|
|
authorized Ticket handoff while preserving a governed Ticket reference.
|
|
|
|
Cases does not own institutional Service, Party, representation, identity,
|
|
address, Mandate, Decision, file, workflow, or task lifecycles. The `/cases`
|
|
workspace now supplies list/detail, status/title revision, history, and timeline
|
|
surfaces. A case can remain tenant-visible or become restricted to its creator,
|
|
case administrators, explicit user/group grants, and assignment-derived
|
|
function, function-assignment, or organization-unit grants. The detail surface
|
|
uses the shared reference selector to manage those grants; list, detail,
|
|
history, timeline, and update paths all apply the same fail-closed ACL.
|
|
|
|
See [docs/CONCEPT.md](docs/CONCEPT.md) for the current module concept.
|
|
|
|
## Data-subject requests
|
|
|
|
Cases contributes `privacy.dsar.cases`. It reports exact-tenant access grants
|
|
and operator attribution, plus minimized case lifecycle data when an explicit
|
|
Cases reference is supplied and corroborated. Raw snapshots, metadata, search
|
|
text, free-text reasons, event payloads, evidence identifiers, request digests,
|
|
idempotency keys, audit internals, and unrelated access subjects are excluded.
|
|
Historical case evidence is retained; current open case and active access facts
|
|
require authorized manual review through the existing lifecycle. Applicant
|
|
identity correlation remains a Parties responsibility and is never guessed
|
|
from a case's party references.
|
|
|
|
## Ticket escalation
|
|
|
|
When Tickets requests escalation, Cases rechecks tenant membership and
|
|
`cases:case:create`, resolves the exact active Case type and its initial status,
|
|
and derives a deterministic Case ID from the Ticket and idempotency key. A retry
|
|
returns the same Case. The Case keeps only the stable Ticket reference, source
|
|
revision, number, and authorized handoff note in governed context; it does not
|
|
copy Ticket comments, attachments, participants, or lifecycle state. If Cases
|
|
is absent or the configured type is unavailable, Tickets remains usable and
|
|
shows the integration consequence to the operator.
|