S-26 · Self-service: resume an existing registration after page refresh #111

New Issue

2026-07-22T08:41:29Z

not commented

2026-07-22 08:41:29 +00:00

Outcome: A signed-in zorgprofessional who reloads the self-service portal (or returns later) can get back to their existing in-flight registration — and its actions (Documenten aanleveren, Trek aanvraag in) — instead of being dropped back to a blank submit form with the reference lost.

Problem today: All post-submit state in apps/self-service/src/app/registration/registration-page.ts lives in in-memory Angular signals (reference, submitted, documentsProvided, …). On refresh the component is recreated, every signal resets, and there is no way back:

the reference is not in the URL (single route '', no /registrations/:id);
nothing is persisted (no localStorage/sessionStorage);
there is no self-service read endpoint — the BFF exposes only POST for self-service (/self-service/registrations, /{id}/withdraw, /{id}/documents), so even a smarter frontend has nothing to fetch on load.

The reference and the upload/withdraw actions therefore become permanently unreachable after a reload.

Acceptance:

Scenario: resume after refresh — Given jan-burger has submitted a registration, When they reload the portal, Then they see their existing registration (reference + status) and can still provide documents / withdraw, not a blank submit form.
Scenario: owner-scoped lookup — The lookup is scoped to the DigiD token's bsn; a user never sees another citizen's registration.
Scenario: no open registration — A user with no in-flight registration sees the submit form as today.
(Consider) reference reflected in the route so a reload is deep-linkable.

Touches: services/bff (new owner-scoped GET /self-service/registrations reading the DigiD bsn), services/domain (query for the citizen's current registration), apps/self-service (load-on-init + route/state restore), api-client (regenerated), acceptance + e2e tests.

Out of scope: Any change to the openbaar (public) register; behandel/beheer portals; historical/closed registrations (start with the current in-flight one).

Definition of Done

This linked Gitea issue exists and is on the right milestone.
Failing test written and committed first (test(scope): … (refs #NN)).
Implementation makes the test pass (feat(scope): … (refs #NN)).
Refactor commit follows if structure improved.
Conventional Commit messages referencing this issue.
All Gitea Actions CI jobs green (or make ci green while no runner exists).
docker compose up from a fresh clone reaches green health checks within 3 minutes.
Docs touched if behaviour, contracts, or operations changed.
ADR added in docs/architecture/ if a non-obvious decision was made.
Demo note appended to docs/demo-script.md if the slice is user-visible.
This issue closed by the merging PR (closes #NN).

**Outcome:** A signed-in zorgprofessional who reloads the self-service portal (or returns later) can get back to their existing in-flight registration — and its actions (Documenten aanleveren, Trek aanvraag in) — instead of being dropped back to a blank submit form with the reference lost. **Problem today:** All post-submit state in `apps/self-service/src/app/registration/registration-page.ts` lives in in-memory Angular signals (`reference`, `submitted`, `documentsProvided`, …). On refresh the component is recreated, every signal resets, and there is no way back: - the reference is not in the URL (single route `''`, no `/registrations/:id`); - nothing is persisted (no `localStorage`/`sessionStorage`); - there is **no self-service read endpoint** — the BFF exposes only `POST` for self-service (`/self-service/registrations`, `/{id}/withdraw`, `/{id}/documents`), so even a smarter frontend has nothing to fetch on load. The reference and the upload/withdraw actions therefore become permanently unreachable after a reload. **Acceptance:** - `Scenario: resume after refresh` — Given jan-burger has submitted a registration, When they reload the portal, Then they see their existing registration (reference + status) and can still provide documents / withdraw, not a blank submit form. - `Scenario: owner-scoped lookup` — The lookup is scoped to the DigiD token's bsn; a user never sees another citizen's registration. - `Scenario: no open registration` — A user with no in-flight registration sees the submit form as today. - (Consider) reference reflected in the route so a reload is deep-linkable. **Touches:** `services/bff` (new owner-scoped `GET /self-service/registrations` reading the DigiD bsn), `services/domain` (query for the citizen's current registration), `apps/self-service` (load-on-init + route/state restore), `api-client` (regenerated), acceptance + e2e tests. **Out of scope:** Any change to the openbaar (public) register; behandel/beheer portals; historical/closed registrations (start with the current in-flight one). ## Definition of Done - [ ] This linked Gitea issue exists and is on the right milestone. - [ ] Failing test written and committed first (`test(scope): … (refs #NN)`). - [ ] Implementation makes the test pass (`feat(scope): … (refs #NN)`). - [ ] Refactor commit follows if structure improved. - [ ] Conventional Commit messages referencing this issue. - [ ] All Gitea Actions CI jobs green (or `make ci` green while no runner exists). - [ ] `docker compose up` from a fresh clone reaches green health checks within 3 minutes. - [ ] Docs touched if behaviour, contracts, or operations changed. - [ ] ADR added in `docs/architecture/` if a non-obvious decision was made. - [ ] Demo note appended to `docs/demo-script.md` if the slice is user-visible. - [ ] This issue closed by the merging PR (`closes #NN`).

not added the area:bff area:portal-self-service type:slice labels 2026-07-22 08:41:29 +00:00

not added this to the Iteration 2 — Flow Completeness milestone 2026-07-22 08:44:15 +00:00

not changed title from ~~Self-service: resume an existing registration after page refresh~~ to S-26 · Self-service: resume an existing registration after page refresh

2026-07-22 08:45:04 +00:00