Repository navigation
Fix relations to object folder - #1054
Conversation
|
4e30e1d to
5bbf24c
Compare
|
|
@kingjia90 Can you review this also please? |
|
@robertSt7 Can you review this also please? |
|
@markus-moser Can you review this also please? |
There was a problem hiding this comment.
Pull request overview
Updates GraphQL relation resolution to recognize data object folders and refreshes Studio build artifacts.
Changes:
- Resolves folder descriptors using
_object_folder. - Improves missing class-type handling.
- Updates generated Studio assets and build paths.
Reviewed changes
Copilot reviewed 12 out of 27 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
src/GraphQL/PropertyType/ObjectsType.php |
Adds folder resolution for object properties. |
src/GraphQL/General/AnyTargetType.php |
Adds folder resolution for editable relations. |
src/GraphQL/DataObjectType/AbstractRelationsType.php |
Adds folder union membership and resolution. |
src/GraphQL/ClassTypeDefinitions.php |
Avoids undefined-key warnings. |
.../static/js/remoteEntry.js.LICENSE.txt |
Adds dependency licenses. |
.../static/js/main.9c3ad8a2.js.LICENSE.txt |
Adds bundle license. |
.../static/js/main.9c3ad8a2.js |
Adds generated main bundle. |
.../static/js/async/840.4693a4bb.js.LICENSE.txt |
Adds dependency licenses. |
.../static/js/async/696.3b1d6da3.js.LICENSE.txt |
Adds bundle license. |
.../static/js/async/696.3b1d6da3.js |
Adds generated configuration chunk. |
.../async/__federation_expose_plugins.c4cf01bd.js.LICENSE.txt |
Adds plugin chunk license. |
.../async/__federation_expose_plugins.c4cf01bd.js |
Adds generated plugin chunk. |
.../async/__federation_expose_default_export.87553f32.js.LICENSE.txt |
Adds export chunk license. |
.../async/__federation_expose_default_export.87553f32.js |
Adds generated export chunk. |
.../static/js/109.62a4c31b.js.LICENSE.txt |
Adds runtime dependency licenses. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/mf-stats.json |
Updates module federation path. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/mf-manifest.json |
Updates federation manifest path. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/manifest.json |
Adds new build manifest. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/main.html |
References the new build path. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/exposeRemote.js |
Updates the remote-entry path. |
.../a680030b-9298-45e8-9a3f-ad0bc24086c1/entrypoints.json |
Adds new build entrypoints. |
.../785fd5b2-5311-4070-9fc4-81949c904ac6/manifest.json |
Removes the old manifest. |
.../785fd5b2-5311-4070-9fc4-81949c904ac6/entrypoints.json |
Removes old entrypoints. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Relation/property type resolvers returned a class type definition for object folders, which fails since folders have no class. Route folders to the registered '_object_folder' type instead, and guard ClassTypeDefinitions::get() against undefined indexes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
getTypes() builds the union member types eagerly (via Schema::getTypeMap()).
For a relation field that allows object folders, the 'folder' pseudo-class
reached ClassTypeDefinitions::get('folder') and threw
"type definition folder not found", failing every query against the schema.
Route 'folder' to the _object_folder type, mirroring the resolveType() fix.
resolveType() returns _object_folder for object-folder elements, but the
union never listed it as a possible type, so webonyx rejected folder values
with "resolved to a type that is not a possible type". Register it under the
same querySchemaEnabled('object_folder') guard used by AnyTargetType.
5839932 to
231a762
Compare
|
|
Hey @blankse — the resolveType() fixes look correct, but I think there's one gap left.
Can you mirror that fix into the Thanks! |
AbstractRelationsType::getTypes() only added _object_folder when 'folder' was listed in the field's class restriction. Without a restriction it fell back to ClassTypeDefinitions::getAll(), which is built from the classes table and therefore never contains the folder type - while allowObjectRelation() accepts folders exactly in that case. A folder value in such a relation still failed with "resolved to a type that is not a possible type". Add the folder type to the unrestricted branch as well and cover all three cases (unrestricted, restricted to folder, restricted to a class) with a unit test.
|
Confirmed and fixed in 95719b6.
One open point for you: |
Building the service via ReflectionClass::newInstanceWithoutConstructor() tripped php:S3011 (accessibility bypass). Fetch the real service from the container like ResolveTest does and register/restore the folder type through the public registerDataObjectDataTypes()/getDataObjectDataTypes() API. Also splits the over-long assertion message (php:S103).
|
|
@blankse Thanks for fixing the relations to object folder |







Error when you try to load a relation (editable relations, property) with a folder object value: