feat(self-service): trek aanvraag in — withdrawal action (S-11c-2, closes #12) (#93)
All checks were successful
All checks were successful
## What & why Final sub-slice of **S-11 · Withdrawal (Flow 3)** — the user-facing "trek aanvraag in" action, which **closes #12**. - **self-service portal**: the submit confirmation gains a **"Trek aanvraag in"** button. It withdraws the just-submitted registration via `postSelfServiceRegistrationsIdWithdraw(reference)`; success shows an *ingetrokken* confirmation, a failure is surfaced (`role="alert"`) and the action stays available — same confirm-and-surface pattern as submit. - **acceptance**: `Een registratie intrekken` — owner withdraws → INGETROKKEN + workflow cancelled; a different bsn is reported not-found. - **e2e**: `withdrawal.spec.ts` — DigiD submit → trek aanvraag in → the portal confirms ingetrokken. - **docs**: demo-script + frontend-decisions. Together with S-11a (#88), S-11b (#89), S-11c-1 (#90), this completes the flow: citizen withdraws → domain INGETROKKEN → BPMN message event cancels the process → the case leaves the behandelaar's werkbak. Closes #12 ## Definition of Done - [x] Linked Gitea issue (#12). - [x] Failing tests committed before the implementation. - [x] Implementation makes the tests pass. - [x] Conventional Commits referencing the issue (`refs #12`). - [ ] CI green — all Gitea Actions jobs. - [x] `docker compose up` unaffected. - [x] Docs updated (demo-script + frontend-decisions). - [x] ADR — ADR-0014 (from S-11b) covers the cancellation decision; nothing new here. ## Notes for reviewers - Full local gate run before pushing: `dotnet format --verify-no-changes` clean; `make unit` green (Acceptance **11** incl. the 2 new withdrawal scenarios, Big 95, BFF 30, Acl 27, EventSubscriber 19); self-service lint/test/build green (9 tests, incl. the 2 new withdraw tests). - `withdrawal.spec.ts` waits on the *ingetrokken* confirmation (which only renders after the withdraw POST returns), so it can't cancel the request early (the 499 lesson from #87). Live-validated by verify-stack. Reviewed-on: #93
This commit was merged in pull request #93.
This commit is contained in:
22
tests/acceptance/Features/EenRegistratieIntrekken.feature
Normal file
22
tests/acceptance/Features/EenRegistratieIntrekken.feature
Normal file
@@ -0,0 +1,22 @@
|
||||
# language: en
|
||||
# Drives S-11 (#12). A zorgprofessional withdraws their own submitted registration ("trek aanvraag
|
||||
# in"): it advances to INGETROKKEN and its running workflow is cancelled (ADR-0014). Only the owner
|
||||
# may withdraw — another bsn is told not-found. Exercised against in-memory stand-ins for the store
|
||||
# and the Workflow Client; the live Flowable message correlation is verified by the domain check.
|
||||
Feature: Een registratie intrekken
|
||||
Als zorgprofessional wil ik mijn ingediende registratie kunnen intrekken
|
||||
zodat een aanvraag die ik niet meer wil niet in behandeling blijft.
|
||||
|
||||
Scenario: De zorgprofessional trekt zijn eigen registratie in
|
||||
Given a submitted registration with a running process
|
||||
When the zorgprofessional withdraws it
|
||||
Then the withdrawal succeeds
|
||||
And the registration has status "INGETROKKEN"
|
||||
And the running process is cancelled
|
||||
|
||||
Scenario: Een andere zorgprofessional kan de registratie niet intrekken
|
||||
Given a submitted registration with a running process
|
||||
When a different zorgprofessional tries to withdraw it
|
||||
Then the withdrawal is reported not found
|
||||
And the registration has status "INGEDIEND"
|
||||
And the running process is not cancelled
|
||||
Reference in New Issue
Block a user