5 Commits

Include renames

Author	SHA1	Message	Date
notandClaude Opus 4.8	dc4822e53d	fix(infra): deploy diploma-eligibility DMN via dmn-api, not a process .bar (refs #14) ... flowable-rest does not cascade a .dmn bundled inside a process .bar into the DMN engine: the resource is stored but no decision is created, so the DMN service task fails at runtime with FlowableObjectNotFoundException. Deploy the DMN to the DMN engine via /dmn-api/dmn-repository/deployments and the BPMN to the process engine separately; the service task resolves the decision across deployments by key (verified live: Buitenlands->CBGV_ADVIES, Binnenlands->DIRECT). Also move the DMN's doc comment inside <definitions>: Flowable's DMN XML converter rejects a comment between the <?xml?> declaration and the root element (XMLStreamReader not in START_DOCUMENT/START_ELEMENT state), unlike its BPMN one. seed-config.sh now seeds both raw workflow files instead of building a .bar. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 09:05:41 +02:00
notandClaude Opus 4.8	d5100d9d41	fix(infra): deploy BPMN + DMN as one .bar so the inline decision resolves (S-13, refs #14) ... The DMN service task resolves its decision scoped to the process's own deployment, so a standalone .dmn deployment was invisible (FlowableObjectNotFoundException: No decision found for key: diploma-eligibility). Bundle registratie.bpmn + diploma-eligibility.dmn into a single registratie.bar and deploy it as one deployment, giving the decision the process's parent deployment id. flowable-rest does not expose the dmn-api app, so co-deployment is the way in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 11:38:44 +02:00
notandClaude Opus 4.8	dc9cf41dc8	feat(workflow): diploma-eligibility DMN + CBGV-advies routing (S-13, refs #14) ... Add workflows/diploma-eligibility.dmn (origin → route) and wire the registratie BPMN: a businessRuleTask evaluates it inline and an exclusive gateway routes a foreign diploma through a new CBGVAdvies user task before Beoordelen, a domestic one straight there (ADR-0016). Deploy the DMN to Flowable's DMN engine and stage both workflow files into the fl-bpmn volume. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 12:01:37 +02:00
notandClaude Opus 4.8	f3e9db7147	feat(infra): wire OpenZaak → Open Notificaties notifications (refs #56) ... Completes the S-01-c wiring so a zaak created in OpenZaak is published to NRC: - OpenZaak: a zgw_consumers 'nrc' service + notifications_config (setup_configuration), publishing as big-reference-seed. NOTIFICATIONS_DISABLED stays true for OpenZaak-only bring-ups (OZ_NOTIFICATIONS_DISABLED) so the ACL integration test doesn't 500; the full/local stacks and stack-up set it false. - NRC: the JWT credential, an 'ac' service + autorisaties_api delegation to OpenZaak's Autorisaties API, and the 'zaken' kanaal. nrc-init now runs setup_configuration; its data.yaml is delivered via the rr-nrc-config volume (seed-config.sh nrc), mirroring oz. - nrc-beat added to every stack: NRC accepts a notification then drains it via a scheduled execute_notifications task — without beat, nothing is delivered. Interval 5s. Applied across the standalone, full, and local-bind-mount composes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 14:29:12 +02:00
notandClaude Opus 4.8	b349dff496	refactor(infra): use upstream images verbatim, seed config via docker cp (refs #30) ... Drops the inline-build images for the upstream services. The compose now references the published images directly (openzaak/open-zaak, openzaak/open-notificaties, keycloak, curl, flowable-rest) with no build for them, and the config they need is streamed into external named volumes by infra/seed-config.sh: rr-oz-config -> oz-init /app/setup_configuration (data.yaml) rr-kc-realms -> keycloak /opt/keycloak/data/import (realm exports) rr-fl-bpmn -> flowable-init /work (registratie.bpmn) How: the seeder creates each volume, `docker create`s a throwaway helper that mounts it, `docker cp`s the files in, and removes it. docker cp streams over the Docker API, so it works in Docker-in-Docker (the CI runner) where bind mounts mount empty. It uses plain `docker create`/`cp` — NOT `docker compose create`, which podman-compose (local dev) lacks. `external: true` fixed names keep the volumes identical across docker compose and podman-compose. Consequence: bare `docker compose up` no longer self-seeds, so use `make up` (seeds then starts). Every `*-up` target seeds first; `*-down` removes the external volume. acl/bff are still built (they're our apps, not upstream images). Verified end-to-end on podman-compose: `make keycloak-up` seeds rr-kc-realms, the upstream Keycloak mounts it, and --import-realm imports all four realms (digid realm returns 200). Seeder runs in ~2s. Docs updated: gitea-actions-gotchas.md, ci.md, openzaak.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 10:22:14 +02:00