When attempting to use ?include for a related field that is not able to have its referenced types discerned in calculateRelatableResourceTypes and subsequently getRelatableResourceTypesFromFieldDefinition the request causes an error that is not intuitive. I'm not sure if this is something that JSON:API can/should guard against as it happened from another module. However it was a little jarring and took me a little while to understand what's happening, so at the very least I thought it'd be a good talking point.
To reproduce
The error looks something like:
{
"title": "Bad Request",
"status": 400,
"detail": "`field_ref_dynamic` is not a valid relationship field name. Possible values: node_type, revision_uid, uid, menu_link, field_ref_dynamic."
}The confusions comes from; the field is not valid but you can use the field.
In this specific example; getRelatableResourceTypesFromFieldDefinition target_type, handler_settings are both null so the settings of the field cannot be understood by the method. This results in the relatable resource types configuration array being empty for field_ref_dynamic. When resolving an include path in resolveInternalIncludePath it explicitly catches this and raises the error.
Perhaps the configuration array should be filtered of empty settings values before in calculateRelatableResourceTypes before the resolver.
Use a core entity reference field.
Closed: outdated
9.5
Last updated
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Been in PNMI for 4 years so safe to say it can be closed out I believe.
If still a valid feature request please reopen updating issue summary for how it pertains to D10
Thanks!
🐛 ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type" Fixed has been committed.