fix(render): an imported $ref still resolves its object source - #3385
Open
rubenvdlinde wants to merge 1 commit into
Open
fix(render): an imported $ref still resolves its object source#3385rubenvdlinde wants to merge 1 commit into
rubenvdlinde wants to merge 1 commit into
Conversation
A property written `{"$ref": "nc-organisation"}` resolved fine, and
silently stopped resolving the moment it had been through an import.
extendObjectSourceRefs() required the ref to be a STRING. ImportHandler
rewrites a `$ref` slug to the resolved schema id, so what a descriptor
ships and what the database ends up holding are different types, and the
int form fell straight through the guard to `continue`. The property then
rendered as its raw uuid with no error anywhere: the reference looks
resolved, because it HAS an id.
getSchema() has always accepted `int|string`, so the guard was the only
thing rejecting it.
Measured on a live instance, same publication and same organisation:
$ref "nc-organisation" -> inlines the organisation
$ref 38 -> returns the raw uuid
$ref 38, with this fix -> inlines the organisation
This blocks any leaf app referencing a virtual schema, which is every app
that is about to point `publication.organization` at OpenRegister's
shared organisation rather than shipping its own.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Quality Report — ConductionNL/openregister @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-specs | ✅ | ||||
| test-l10n | ✅ | ||||
| test-l10n-parity | ✅ | ||||
| format | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| check-l10n-js | ✅ | ||||
| composer | ✅ | ✅ 174/174 | |||
| npm | ✅ | ✅ 543/543 | |||
| 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 18:28 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
1 participant
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.
A property written
{"$ref": "nc-organisation"}resolved fine, and silently stopped resolving the moment it had been through an import.extendObjectSourceRefs()required the ref to be a string.ImportHandlerrewrites a$refslug to the resolved schema id, so what a descriptor ships and what the database ends up holding are different types — and the int form fell straight through the guard tocontinue.The property then rendered as its raw uuid with no error anywhere. That is the hard part: the reference looks resolved, because it has an id.
getSchema()has always acceptedint|string, so the guard was the only thing rejecting it.Measured, on one live instance, same publication and same organisation
$ref_extend[]=organizationreturns"nc-organisation"38(what the import writes)38, with this fixWhy it matters now
This blocks any leaf app referencing a virtual schema — which is every app about to point
publication.organizationat OpenRegister's shared organisation (#3363) instead of shipping its own collidingorganizationschema. I found it while doing exactly that in opencatalogi.4 regression tests, including the negative cases (empty ref, null, array).
tests/Unit/Service/Object: 2,284 tests green. phpcs, phpstan clean.🤖 Generated with Claude Code