Symptom
With the seeders now running under a system identity (#1227), seedBbvStamData gets past the Anonymous refusal and fails on the next thing:
WARN BBV stam-data seeding failed: The required properties (budgetId, programmeId,
taskFieldCode, taskFieldName, revenue, expenses, administrationId) are missing.
The seeder writes task-field catalogue rows. Those property names are not its shape at all.
Diagnosis: a slug collision
Two unrelated schemas declare the same slug in the same register:
| declared in |
slug |
title |
required |
lib/Settings/shillinq_register.json |
Taakveld |
Task Field |
code, name, mainFunction, overheidslaag |
lib/Settings/register.d/bookkeeping-programmabegroting.json |
Taakveld |
Taakveld |
budgetId, programmeId, taskFieldCode, taskFieldName, revenue, expenses, administrationId |
The first is a catalogue of BBV task fields (gemeente/provincie/waterschap). The second is a programmabegroting budget line per task field. Different concepts, one slug.
BbvSeedService::CATALOGUES targets 'schema' => 'Taakveld' for all three taakvelden files. OpenRegister resolves that slug to whichever schema wins, and here it resolves to the budget line — so every catalogue row is validated against the wrong required list and rejected.
Live: searchObjectsBySlug('shillinq','Taakveld') resolves and returns 0 rows — consistent with a catalogue that has never been written.
Why it was invisible until now
The seed previously failed earlier, on User 'Anonymous' does not have permission to 'create'. Every attempt died at the identity gate, so the payload was never validated and the collision never surfaced. Fixing the outer error is what made the inner one reachable — the same sequence as decidiq#886/#904, where clearing 12 identity failures exposed 2 format ones underneath.
Why I am not patching it
The fix is a rename, and a schema slug is a frozen identifier: OpenRegister resolves objects by it, so changing one orphans whatever is stored under it. Choosing which of the two keeps Taakveld — and what happens to existing objects under the loser — is a data decision with migration consequences, not a mechanical edit.
Whoever picks it up needs to decide:
- Which concept keeps
Taakveld. (The programmabegroting one already reads as the newer arrival.)
- What the other becomes —
BbvTaakveld is taken by a third schema, so a third name is needed.
- Whether any stored objects exist under the loser on real instances, and what migrates them.
A gate that fails a register carrying two schemas with one slug would have caught this at authoring time.
Found 2026-08-25 while verifying #1227 on a live instance.
Symptom
With the seeders now running under a system identity (#1227),
seedBbvStamDatagets past theAnonymousrefusal and fails on the next thing:The seeder writes task-field catalogue rows. Those property names are not its shape at all.
Diagnosis: a slug collision
Two unrelated schemas declare the same slug in the same register:
lib/Settings/shillinq_register.jsonTaakveldcode, name, mainFunction, overheidslaaglib/Settings/register.d/bookkeeping-programmabegroting.jsonTaakveldbudgetId, programmeId, taskFieldCode, taskFieldName, revenue, expenses, administrationIdThe first is a catalogue of BBV task fields (gemeente/provincie/waterschap). The second is a programmabegroting budget line per task field. Different concepts, one slug.
BbvSeedService::CATALOGUEStargets'schema' => 'Taakveld'for all three taakvelden files. OpenRegister resolves that slug to whichever schema wins, and here it resolves to the budget line — so every catalogue row is validated against the wrong required list and rejected.Live:
searchObjectsBySlug('shillinq','Taakveld')resolves and returns 0 rows — consistent with a catalogue that has never been written.Why it was invisible until now
The seed previously failed earlier, on
User 'Anonymous' does not have permission to 'create'. Every attempt died at the identity gate, so the payload was never validated and the collision never surfaced. Fixing the outer error is what made the inner one reachable — the same sequence as decidiq#886/#904, where clearing 12 identity failures exposed 2 format ones underneath.Why I am not patching it
The fix is a rename, and a schema slug is a frozen identifier: OpenRegister resolves objects by it, so changing one orphans whatever is stored under it. Choosing which of the two keeps
Taakveld— and what happens to existing objects under the loser — is a data decision with migration consequences, not a mechanical edit.Whoever picks it up needs to decide:
Taakveld. (The programmabegroting one already reads as the newer arrival.)BbvTaakveldis taken by a third schema, so a third name is needed.A gate that fails a register carrying two schemas with one slug would have caught this at authoring time.
Found 2026-08-25 while verifying #1227 on a live instance.