Niek Otten
9997da8beb
All checks were successful
## What & why Before this change the self-service confirmation and the openbaar register showed **different** identifiers, so a citizen could not look their registration back up (#78). Now both surface the same **reference**: - **domain → ACL (write):** the domain `registrationId` is set as the zaak's `identificatie` on `POST /zaken`. - **event-subscriber → ACL (read):** the subscriber reads the zaak's `identificatie` back through the ACL (§8.1 — only the ACL talks to ZGW) via a new `POST /zaken/reference`, and stores it on the projection row **and** the `processed_notifications` replay log. - **BFF + openbaar:** the public view exposes `id/status/reference` (never bsn/naam) and searches by id or reference; the register's "Referentie" column shows the reference. Storing the reference in the replay log keeps ADR-0008's **rebuild-is-log-only** invariant intact — `/admin/rebuild` reproduces the reference without re-reading the ACL. Decision recorded in **ADR-0012**. ## Definition of Done - [x] Linked issue: #78 - [x] Tests written first; red → green per layer - [x] Unit + acceptance green (`make unit`): domain 49, acl 27, bff 20, event-subscriber 19, acceptance 7 - [x] Frontend lint + test green (`nx run-many -t lint test`) - [x] Mutation ≥ break(90): acl 100%, event-subscriber 100%, bff 100%, domain 98.41% (pre-existing FlowableWorkflowClient baseline, untouched) - [x] e2e extended: confirmation reference == register reference - [x] openapi.json + api-client regenerated (drift guard green) - [x] ADR-0012 added; demo-script note appended - [x] `Acl__BaseUrl` wired for the subscriber in compose closes #78 Reviewed-on: #79
42 lines
2.1 KiB
C#
42 lines
2.1 KiB
C#
namespace EventSubscriber.Application;
|
|
|
|
/// <summary>
|
|
/// An inbound NRC (Open Notificaties) notification, as Open Notificaties POSTs it to an
|
|
/// abonnement callback. Only the fields the projection needs are modelled; the full ZGW
|
|
/// "Notificatie" resource also carries <c>aanmaakdatum</c> and <c>kenmerken</c> which the
|
|
/// minimal projection ignores (bsn is deferred — see ADR-0008). For a <c>zaken</c>/<c>zaak</c>/<c>create</c>
|
|
/// notification <c>hoofdObject</c> and <c>resourceUrl</c> are both the created zaak's URL.
|
|
/// </summary>
|
|
public sealed record Notification(
|
|
string Kanaal,
|
|
string Resource,
|
|
string Actie,
|
|
Uri ResourceUrl,
|
|
Uri? HoofdObject = null)
|
|
{
|
|
/// <summary>A zaak being created — projected as INGEDIEND.</summary>
|
|
public bool IsZaakCreated =>
|
|
Kanaal == "zaken" && Resource == "zaak" && Actie == "create";
|
|
|
|
/// <summary>A status being set on a zaak — the approval, projected as INGESCHREVEN (S-09b). In the
|
|
/// walking skeleton the only status ever set after creation is the approval, and the subscriber may
|
|
/// not read OpenZaak (§8.1), so any status-create is taken as the approval.</summary>
|
|
public bool IsZaakStatusSet =>
|
|
Kanaal == "zaken" && Resource == "status" && Actie == "create";
|
|
|
|
/// <summary>The zaak URL this notification concerns — <c>hoofdObject</c> (the zaak) for a status
|
|
/// notification, else the resource URL (which, for a zaak-create, is the zaak).</summary>
|
|
public Uri ZaakUrl => HoofdObject ?? ResourceUrl;
|
|
|
|
/// <summary>The zaak UUID used as the projection key — the trailing segment of <see cref="ZaakUrl"/>.</summary>
|
|
public string ZaakId => ZaakUrl.Segments[^1].Trim('/');
|
|
|
|
/// <summary>
|
|
/// A deterministic dedup key. Open Notificaties carries no notification id and may
|
|
/// redeliver, so the key is derived from the immutable notification content: two
|
|
/// deliveries of the same zaak-create collapse to one. (NRC may also deliver
|
|
/// out of order; the projector tolerates that — order does not change the outcome.)
|
|
/// </summary>
|
|
public string IdempotencyKey => $"{Kanaal}:{Resource}:{Actie}:{ResourceUrl}";
|
|
}
|