fix(settings): install the declarative schema annotations on import - #1704
Merged
rubenvdlinde merged 1 commit intoSep 3, 2026
Merged
Conversation
loadConfiguration() called the schema-KEYS reconciler but never the ANNOTATIONS one, so importing the register created the schemas without the `x-openregister-*` blocks declared alongside them in dossiq_register.json. On a fresh instance that means the task calculations never arrive: isTerminalStatus never materialises, so every completed task reads false and the widgets whose entire filter is isTerminalStatus = false keep showing finished work; and daysUntilDue does not exist to extend, so every due-date column renders blank. Both failures are silent. The e2e suite caught this on a clean CI install after the same tests passed locally, because I had repaired the dev instance BY HAND before testing it. The dev box had the calculations; a clean install never would. That is the whole reason the assertions are written against the API rather than the UI. Proven both directions on a real import, after stripping schema 173 back to its fresh-install state: import as shipped -> blocksCase only import with this -> isTerminalStatus, daysUntilDue, daysOverdue The foreign task schema stays untouched either way, so the register-scoped resolver still holds. Idempotent, so it is safe on every import. Verified: 2794 PHPUnit tests pass, the 4 demo-caseload e2e tests pass, phpcs clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rubenvdlinde
requested review from
WilcoLouwerse,
bbrands02 and
rjzondervan
as code owners
September 3, 2026 05:37
Contributor
Quality Report — ConductionNL/dossiq @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| check-vue3-compile | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| check-l10n-js | ✅ | ||||
| composer | ✅ | ✅ 106/106 | |||
| npm | ✅ | ✅ 540/540 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ⏭️ | ||||
| Playwright | ⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-09-03 05:42 UTC
Download the full PDF report from the workflow artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
loadConfiguration()called the schema-keys reconciler but never the annotations one. Importing the register creates the schemas, but thex-openregister-*blocks declared alongside them indossiq_register.jsondo not survive onto the live schema.On a fresh instance the task calculations therefore never arrive:
isTerminalStatusnever materialises, so every completed task readsfalseand the widgets whose entire filter isisTerminalStatus = falsekeep showing finished work.daysUntilDuedoes not exist to extend, so every due-date column renders blank.Both failures are silent. Nothing errors, nothing logs.
How it was found
The e2e suite caught it on the
developmentpush run, on a clean CI install, after the same two tests had passed locally.They passed locally because I had repaired the dev instance by hand before testing it. The dev box had the calculations; a clean install never would. That is exactly why those assertions are written against the API rather than the UI, and it is the reason the test is worth more than the fix.
Proven both directions
Measured on a real import, after stripping schema 173 back to its fresh-install state:
blocksCaseonlyisTerminalStatus, daysUntilDue, daysOverdueThe foreign
taskschema (id 52, owned by another app) stays untouched in both cases, so the register-scoped resolver from #1676 still holds.Verified
demo-caseloadPlaywright tests pass, which are the ones that failed ondevelopmentIdempotent, so it is safe on every import.
🤖 Generated with Claude Code