I have run into a situation that prevents me from filtering for the value of a base field of an entity.
I have an entity type called "value" with bundle = "type".
The bundle_entity_type is set to "value_type".
The entity also has a base field that is called "value_type" and is of type string.
Now when I try to filter for the latter things go wrong. A request for
GET {{base_url}}/{{sitepath}}/jsonapi/value/generic_list_value?filter[value_type]=abc
returns an error:
"errors": [
{
"title": "Bad Request",
"status": "400",
"detail": "Invalid nested filtering. The field `value_type`, given in the path `value_type` is incomplete, it must end with one of the following specifiers: `id`.",
...
I think jsonapi misdetects the "value_type" name in the filter as to mean the config entity "value_type".
At least, if I try adding ".id" as suggested:
GET {{base_url}}/{{sitepath}}/jsonapi/value/generic_list_value?filter[value_type.id]=abc
The error becomes about config entities:
"errors": [
{
"title": "Bad Request",
"status": "400",
"detail": "Filtering on config entities is not supported by Drupal\u0027s entity API. You tried to filter on a Value Type config entity.",
...
I could not find a syntax that lets me filter by the string field "value_type".
I think this issue is due to the special casing of "type" (and "id") in ResourceTypeRepository::getFieldMapping. The check there that should detect naming conflicts is currently broken (see #3077661: Check for conflict in fieldname mapping does not work), so the code continues. An error occurs later on as described above.
NB: Fixing #3077661 would cause an exception to be thrown, with a more meaningful message, but this issue here would still not be resolved.
It looks like that it is forbidden to have an entity type with a bundle field named “type” and a field which is constructed like “{$entity_type_id}_type”. However Drupal does not prevent you from creating such an entity in any way and suddenly by installing a core module there are errors / exceptions. We are going to solve our issue by renaming the bundle field, however it is better to add some naming constraints to the Drupal core so that such things never occur.
(Thanks to hchonov who helped me diagnose this up to this point.)