feat(#13): S-12b — Workflow Client user-tasks + Beoordelen userTask #83

Merged

not merged 7 commits from feat/13-workflow-user-tasks into main 2026-07-15 08:53:35 +00:00

Conversation 0 Commits 7 Files Changed 6

+279 -14

not commented 2026-07-15 07:25:24 +00:00

Contributor

Copy Link

Copy Source

What & why

Second sub-slice of S-12 (#13) — the Workflow Client gains behandelaar user-task operations, and the process model gains the beoordeling step.

• BPMN: registratie.bpmn now parks at a Beoordelen userTask (candidate group behandelaar) after OpenZaakAanmaken; registrationId rides along as a process variable so the werkbak can correlate each task to its aggregate.
• Workflow Client (IUserTaskClient, the only code that talks to Flowable §8.2):
  • GetOpenBeoordelingenAsync() — the werkbak (open Beoordelen tasks + their registrationId)
  • ClaimAsync(taskId, behandelaar)
  • CompleteBeoordelingAsync(taskId, besluit) — carries the decision into the process as the besluit variable
• Live integration: verify-domain now drives the full user-task lifecycle against a real Flowable — after the worker opens the zaak, it polls for the task, claims it as merel-behandelaar, completes it (goedkeuren), and asserts the process finishes. This proves the exact REST contract (service/runtime/tasks/query + …/{id} claim/complete) the client depends on.

The walking skeleton is unaffected: the temporary /approve path still sets the zaak status directly; wiring the domain decision to complete this task (and driving the werkbak from the BFF) lands in S-12c.

Definition of Done

• Linked issue: #13 (umbrella; refs, does not close)
• Tests first; red → green
• Unit + acceptance green (make unit): domain 76, acceptance 9 (acl/event-subscriber/bff unaffected)
• Mutation ≥ break(90): domain 100% (killed the new survivors and the pre-existing FlowableWorkflowClient baseline)
• Live Flowable user-task lifecycle asserted in verify-domain
• CI green (pending)

Part of #13.

## What & why Second sub-slice of **S-12 (#13)** — the **Workflow Client gains behandelaar user-task operations**, and the process model gains the beoordeling step. - **BPMN:** `registratie.bpmn` now parks at a `Beoordelen` **userTask** (candidate group `behandelaar`) after `OpenZaakAanmaken`; `registrationId` rides along as a process variable so the werkbak can correlate each task to its aggregate. - **Workflow Client** (`IUserTaskClient`, the only code that talks to Flowable §8.2): - `GetOpenBeoordelingenAsync()` — the werkbak (open `Beoordelen` tasks + their `registrationId`) - `ClaimAsync(taskId, behandelaar)` - `CompleteBeoordelingAsync(taskId, besluit)` — carries the decision into the process as the `besluit` variable - **Live integration:** `verify-domain` now drives the full user-task lifecycle against a real Flowable — after the worker opens the zaak, it polls for the task, claims it as `merel-behandelaar`, completes it (`goedkeuren`), and asserts the process finishes. This proves the exact REST contract (`service/runtime/tasks/query` + `…/{id}` claim/complete) the client depends on. The walking skeleton is unaffected: the temporary `/approve` path still sets the zaak status directly; wiring the domain decision to *complete this task* (and driving the werkbak from the BFF) lands in **S-12c**. ## Definition of Done - [x] Linked issue: #13 (umbrella; `refs`, does not close) - [x] Tests first; red → green - [x] Unit + acceptance green (`make unit`): domain 76, acceptance 9 (acl/event-subscriber/bff unaffected) - [x] Mutation ≥ break(90): **domain 100%** (killed the new survivors *and* the pre-existing `FlowableWorkflowClient` baseline) - [x] Live Flowable user-task lifecycle asserted in `verify-domain` - [x] CI green (pending) Part of #13.

not added 5 commits 2026-07-15 07:25:26 +00:00

test(workflow): user-task client — werkbak query, claim, complete beoordeling (refs #13) ... 57cc3637c9

Red — GetOpenBeoordelingenAsync/ClaimAsync/CompleteBeoordelingAsync do not exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(workflow): user-task client for beoordeling — werkbak, claim, complete (refs #13) ... efd1c06b99

Adds the IUserTaskClient port and implements it on the Workflow Client (the only code
that talks to Flowable, §8.2): query open Beoordelen tasks (werkbak) with their
registrationId, claim a task for a behandelaar, and complete it carrying the besluit
into the process. Registered in DI for later wiring (S-12c).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(workflow): add the Beoordelen behandelaar user task to registratie.bpmn (refs #13) ... 5db55eebf4

After OpenZaakAanmaken the process now parks at a Beoordelen user task (candidate
group behandelaar) until the behandelaar claims and completes it. registrationId
rides along as a process variable so the werkbak correlates each task to its
aggregate. The walking skeleton is unaffected: the temporary /approve path sets the
zaak status directly; wiring the decision to complete this task lands in S-12c/d.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(workflow): verify-domain exercises the Beoordelen user task end-to-end (refs #13) ... 3d561deb05

After the worker opens the zaak, the process parks at Beoordelen. The live check now
polls Flowable for the task (werkbak), claims it as merel-behandelaar, completes it
with besluit=goedkeuren, and asserts the process finishes — proving the exact REST
contract (query/claim/complete) the Workflow Client depends on against a real engine.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(workflow): cover the besluit variable type + start empty-body throw (refs #13) ... 57b8755f9d

Kills two mutation survivors: assert the complete besluit variable's type, and add
the missing start empty-response case (the pre-existing baseline survivor). Domain
mutation score reaches 100%.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added the type:slicearea:workflow labels 2026-07-15 07:25:27 +00:00

not added 1 commit 2026-07-15 07:57:15 +00:00

fix(workflow): query Flowable tasks at service/query/tasks, not runtime/tasks/query (refs #13) ... c53354cd22

The task-query endpoint is service/query/tasks; the wrong path 404'd, so verify-domain's
werkbak poll got an empty body and the JSON parser aborted the check. Correct the path
in the Workflow Client (and its unit test) and make the live-check parser tolerant of a
transient empty/non-JSON body so the poll retries instead of crashing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added 1 commit 2026-07-15 08:29:47 +00:00

fix(workflow): read task query variables from 'variables', not 'processVariables' (refs #13) ... 94a506cbfc

Flowable's POST query/tasks returns the included process variables under the key
'variables' (the request opts in via includeProcessVariables). The client DTO, its
unit test, and the live-check parser all looked for 'processVariables', so the
werkbak never matched a task's registrationId and verify-domain timed out. Verified
by driving a real Flowable instance end-to-end locally: start -> complete external
job -> the Beoordelen task carries registrationId under 'variables'.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not merged commit 4085bdead7 into main 2026-07-15 08:53:35 +00:00

not referenced this issue from a commit 2026-07-15 08:53:36 +00:00

feat(#13): S-12b — Workflow Client user-tasks + Beoordelen userTask (#83)

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

area:acl

area:bff

area:docs

area:domain

area:event-subscriber

area:infra

area:portal-behandel

area:portal-beheer

area:portal-openbaar

area:portal-self-service

area:projection

area:workflow

type:adr-proposal

type:bug

type:chore

type:slice

No labels area:workflow type:slice

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

eho (Edwin van den Houdt)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eho/register-referentie#83