Niek Otten
d4ed0ffc22
All checks were successful
## What & why First sub-slice of **S-12 (#13)** — the **beoordeling decision model** in the Domain Service. Foundation for the behandel-portal: it gives the domain a proper decision lifecycle before any UI/Flowable/BFF work. - **Statuses:** add `InBehandeling` and `Afgewezen` to `RegistrationStatus`. - **Aggregate:** `TakeIntoBehandeling()` (`Ingediend → InBehandeling`, idempotent, guards terminal states); generalise the behandelaar decision — `Approve()` (requires a zaak) and new `Reject()` both act on an `Ingediend`/`InBehandeling` registration → `Ingeschreven`/`Afgewezen`. - **Use-case:** `BeoordeelRegistratie` (`goedkeuren` sets the zaak's final status via the ACL §8.1 → `Ingeschreven`; `afwijzen` → `Afgewezen`, domain-only for now). Idempotent. - **Endpoint:** `POST /registrations/{id}/decide` (`{ "besluit": "goedkeuren" | "afwijzen" }`), superseding the temporary `/approve` (retired when the portal lands, S-12d). - **BDD:** `EenRegistratieBeoordelen.feature` — goedkeuren + afwijzen scenarios (feature-scoped bindings). **Scoped out** to later S-12 sub-slices: Flowable user-task claim/complete + BPMN `userTask` (S-12b), BFF `/behandel/*` + medewerker authz (S-12c), the Angular behandel-portal + e2e (S-12d), and propagating a *rejection* to the zaak/projection via the ACL. ## Definition of Done - [x] Linked issue: #13 (umbrella; this PR `refs`, does not close) - [x] Tests first; red → green per behaviour - [x] Unit + acceptance green (`make unit`): domain 65, acceptance 9 - [x] Mutation ≥ break(90): domain 98.77%, no survivors in new code (the one unkilled mutant is the pre-existing `FlowableWorkflowClient` baseline) - [ ] CI green (pending) Part of #13. Reviewed-on: #82
25 lines
1.2 KiB
Gherkin
25 lines
1.2 KiB
Gherkin
# language: en
|
|
# Drives S-12 (#13). A behandelaar picks up a submitted registration for beoordeling and decides it:
|
|
# goedkeuren enters it in the register (INGESCHREVEN, the zaak's final status set via the ACL, §8.1),
|
|
# afwijzen turns it down (AFGEWEZEN). This scenario exercises the use cases against in-memory
|
|
# stand-ins for the ACL and the store; real Flowable user-task claim/complete arrives in a later
|
|
# sub-slice and is verified live.
|
|
Feature: Een registratie beoordelen
|
|
Als behandelaar wil ik een ingediende registratie beoordelen
|
|
zodat deze wordt ingeschreven of afgewezen.
|
|
|
|
Scenario: Goedkeuren schrijft de registratie in via de ACL
|
|
Given a submitted registration with an opened zaak
|
|
When the behandelaar takes it into behandeling
|
|
Then the registration has status "INBEHANDELING"
|
|
When the behandelaar decides "goedkeuren"
|
|
Then the registration has status "INGESCHREVEN"
|
|
And the zaak's final status is set via the ACL
|
|
|
|
Scenario: Afwijzen wijst de registratie af zonder de ACL
|
|
Given a submitted registration with an opened zaak
|
|
When the behandelaar takes it into behandeling
|
|
And the behandelaar decides "afwijzen"
|
|
Then the registration has status "AFGEWEZEN"
|
|
And the ACL is not asked to set the zaak status
|