not
448896206f
CI / build (pull_request) Successful in 4m31s
CI / lint (pull_request) Successful in 4m46s
CI / unit (pull_request) Successful in 1m35s
CI / frontend (pull_request) Successful in 4m0s
CI / mutation (pull_request) Successful in 6m47s
CI / verify-stack (pull_request) Failing after 17m35s
Builds the four pieces ADR-0028 deliberately left absent, and turns
`NOTIFICATIONS_DISABLED` back off:
- `objecten-celery`, a worker on the Objecten image (mirrors `oz-celery`), plus
`CELERY_BROKER_URL`/`RESULT_BACKEND` on objecten-redis db 1 (db 0 is the cache).
Without it `notifications_api_common` queues the send and nothing ever ships it.
- An `nrc` service + `notifications_config` in Objecten's setup_configuration,
reusing the `big-reference-seed` credential OpenZaak publishes with.
- The `objecten` kanaal in NRC's setup_configuration — the name is fixed by the
Objects API (`NOTIFICATIONS_KANAAL`), and publishing to an unregistered kanaal is
what the failing check reported first.
- `SITE_DOMAIN: objecten.local:8000` + an `objecten.local` network alias: NRC
validates `hoofdObject`/`resourceUrl` with Django's URLValidator, which rejects a
single-label host, so `objecten:8000` is refused with "Voer een geldige URL in."
The alias keeps the dotted host resolvable so the URL still dereferences.
ADR-0029 records it; ADR-0028's ceiling now points there.
Makes `make verify-objecten-notifications` (dc9ca2c) pass.