5f38f761d13c7960233edb5b87e706dcd511b4a6
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  notandClaude Opus 4.8
|
5f38f761d1 |
feat(infra): register RegisterRecord objecttype + published version in Objecttypen (refs #141)
The Objecttypen setup_configuration (3.4.2) can only provision tokens, with no declarative objecttype step, so a registerrecord-init compose one-shot creates the RegisterRecord objecttype + a published v1 over the API once Objecttypen is healthy (idempotent; ADR-0020 self-seed pattern). The schema (infra/objecttypen-registerrecord/registerrecord.schema.json) is public-safe — id, status, reference — mirroring the BFF's OpenbaarEntry, no bsn/naam; dataClassification 'open'. S-19 writes records against it on approval. Config (schema + register.py) is streamed into rr-registerrecord-config by seed-config.sh (main) / bind-mounted (local), same dual pattern as the setup_configuration volumes. Wired into SEED, CFG_VOLS, and the CI log-dump. Verified locally: registerrecord-init registered RegisterRecord v1 published, make verify-registerrecord green, and a re-run is a no-op. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
not
|
0a97fa4bf7 |
S-18b · Objecten API up in compose, wired to Objecttypen (closes #140) (#143)
## What & why S-18b, second of the S-18 (#19) split (after S-18a #139/#142). Stands up the upstream Maykin **Objecten API** in the compose stack and wires it to the Objecttypen API — the authoritative object store the ACL will write register records to (S-19). Closes #140 ### What - **Compose** (main + local): `objecten-db` (**PostGIS** — objects carry geometry), `objecten-redis`, `objecten-init` (RUN_SETUP_CONFIG → migrate + provision token + register the Objecttypen service), `objecten` web (health on `/admin/`, host `:8021`). Verbatim upstream image `maykinmedia/objects-api` pinned to `3.4.0` (nearest release to objecttypes-api `3.4.2`; the two speak over the stable Objecttypes API v2). - **Seed**: `infra/seed-config.sh objecten` streams `infra/objecten/setup_configuration/data.yaml` into the external `rr-objecten-config` volume — same pattern as S-18a. The data.yaml (1) registers **Objecttypen** as a trusted `zgw_consumers` service (`api_type: orc`, api-key auth with the S-18a dev token) so an object can reference its objecttype, and (2) provisions a dev **static API token** so peers (the ACL, S-19) can write objects. - **Wiring**: added to `WAIT_SVCS`, `CFG_VOLS`, the `SEED` invocations, `seed-config.sh`, and the CI log-dump. `objecten-init` waits on `objecttypen` being healthy so the service registration is meaningful end to end. - **Smoke**: `verify-objecten` (`infra/run-objecten-check.sh` + `objecten-check.py`) asserts unauth → 401, token → 200 on `/api/v2/objects`; added as a verify-stack step + a row in the #136 check-summary table. ## Verified locally (end to end, real compose) Seeded + brought up the real `infra/docker-compose.yml` objecten chain (pulls in objecttypen via `depends_on`): `objecten-init` ran setup_configuration — `token_configuration_success` **and** "Successfully executed step: Configuration to connect with external services" — the web reached healthy, and `make verify-objecten` → **"OK — no-auth 401, token 200"**. Confirmed the registered service via the Objecten django shell: ``` objecttypen | orc | http://objecttypen:8000/api/v2/ | api_key ``` YAML (both compose files + ci.yaml) + shell + python all validated; `docker compose config` clean on both files. ## Definition of Done - [x] Failing smoke committed first (`test(infra): …`, "no running objecten container"); implementation makes it pass. - [x] Conventional Commits referencing #140. - [ ] CI green (verify-stack objecten step). - [x] `docker compose up` reaches health (objecten healthy on first poll locally). - [x] Demo note in `docs/demo-script.md`. - [x] Closed by the merging PR (`closes #140`). No new ADR: follows the established verbatim-image + seed-config CG-module pattern (S-18a/ADR-0023-era). 🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #143 |
||
|
not
|
23ea91de32 |
feat(infra): Objecttypen API up in compose with a seeded static token (closes #139) (#142)
## What & why S-18a, first of the S-18 (#19) split. Stands up the upstream Maykin **Objecttypen API** in the compose stack — the objecttype catalogue the register record (S-18b/S-18c, S-19) will build on. Closes #139 ### What - **Compose** (main + local): `objecttypen-db` (Postgres), `objecttypen-redis`, `objecttypen-init` (RUN_SETUP_CONFIG → migrate + provision token), `objecttypen` web (health on `/admin/`, host `:8020`). Verbatim upstream image `maykinmedia/objecttypes-api` pinned to `3.4.2`. - **Seed**: `infra/seed-config.sh objecttypen` streams `infra/objecttypen/setup_configuration/data.yaml` into the external `rr-objecttypen-config` volume — same pattern as OpenZaak/NRC. The data.yaml provisions a dev **static API token** (`tokenauth` setup_configuration step) so peers (Objecten, ACL) can authenticate. - **Wiring**: added to `WAIT_SVCS`, `CFG_VOLS`, the `SEED` invocations, and the CI log-dump. - **Smoke**: `verify-objecttypen` (`infra/run-objecttypen-check.sh` + `objecttypen-check.py`) asserts unauth → 401, token → 200; added as a verify-stack step + a row in the #136 check-summary table. ### Split note #19 was oversized (two CG modules + config + objecttype) → split (§13) into **S-18a** (this), **S-18b** (#140, Objecten wired to Objecttypen), **S-18c** (#141, RegisterRecord objecttype). ## Verified locally (end to end, real compose) Seeded + brought up the real `infra/docker-compose.yml` objecttypen chain: `objecttypen-init` ran setup_configuration (`token_configuration_success`), the web reached healthy, and `make verify-objecttypen` → **"OK — no-auth 401, token 200"**. YAML (both compose files + ci.yaml) + shell + python all validated. ## Definition of Done - [x] Smoke check validates the outcome (live, against the running stack). - [x] Conventional Commits referencing #139. - [ ] CI green — see note. - [x] `docker compose up` reaches health (objecttypen healthy on first poll locally). - [x] Demo note in `docs/demo-script.md`. ## Note on CI Additive (a new service + its own smoke step). The fast jobs are unaffected. The **verify-stack** job still can't go green until the pre-existing 1.27/act_runner-2.0.0 bring-up P0 is resolved (fails on plain `main` too) — but the objecttypen bring-up itself is validated locally above. No new ADR: this follows the established verbatim-image + seed-config CG-module pattern (ADR-0023-era). 🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #142 |
||
|
not
|
ccae27b3da |
feat(workflow): diploma-eligibility DMN routes foreign diplomas via CBGV-advies (S-13, closes #14) (#101)
## What & why S-13: a diploma's origin decides its route. A **DMN** (`diploma-eligibility`) is evaluated inline by the registratie process as a **`businessRuleTask`**; an exclusive gateway routes a **foreign** (Buitenlands) diploma through a new **CBGVAdvies** user task before `Beoordelen`, a **domestic** one straight there (PRD flow 4). The domain's only new job is carrying the diploma origin and passing it as a process start variable. Chose **Option B (DMN in the BPMN)** over the issue's literal "evaluated by the Domain Service via Workflow Client" wording — keeps the decision a first-class workflow artefact and §8.2 clean. Rationale in **ADR-0016** (proposal #100); noted on this issue. Closes #14 ## Definition of Done - [x] Linked Gitea issue (above). - [x] Failing test committed before the implementation. - [x] Implementation makes the test pass. - [x] Conventional Commits referencing the issue (`refs #14`). - [ ] CI green — all Gitea Actions jobs. - [x] `docker compose up` from a fresh clone reaches green health checks within 3 minutes (additive; DMN deployed by flowable-init). - [x] Docs updated (ADR-0016, demo note). - [x] ADR added (`docs/architecture/adr-0016-diploma-eligibility-dmn.md`). - [x] Demo note in `docs/demo-script.md`. ## How it was built (TDD) - **Domain**: `DiplomaOrigin` on the aggregate + submit command; threaded through the process-start port so the Workflow Client emits a `diplomaOrigin` start variable. Red → green. - **DMN + BPMN**: `workflows/diploma-eligibility.dmn` (origin → route); `businessRuleTask` + exclusive gateway + `CBGVAdvies` user task in `registratie.bpmn`; DMN deployed to Flowable's DMN engine by `flowable-init`. - **Both paths**: `Een diploma op herkomst routeren` acceptance scenarios (origin carried into the process) + unit tests; verify-domain drives a foreign registration through CBGVAdvies→Beoordelen and the domestic one straight to Beoordelen — exercising both DMN branches live. ## Notes for reviewers - Deviation from the issue's Option-A wording is deliberate and recorded (ADR-0016); the outcome is unchanged. - The self-service eIDAS→foreign wiring is out of scope here (this slice is area:domain + area:workflow); the domain submit accepts an optional `diplomaOrigin` so the foreign path is drivable. - Local green: domain unit 109, acceptance 15, `dotnet format`, Release build (0 errors), **domain mutation 95.39%** (break 90). The DMN/`businessRuleTask` REST wiring is CI-verified on verify-stack (no local full-stack run here). Reviewed-on: #101 |
||
|
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> |
||
|
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> |