Views does not add relationship data for entity_reference fields not defined in configuration and are multiple

I have replicated this issue (by having it myself ;) ) and can confirm that the suggestion in #2 resolves the problem.

After a lot more digging, I think the previous patch is simply a coincidental fix (obviously since it failed). I think the root cause is that the views module is only adding 'relationship field' data for entity_reference config fields, not base fields on entities.

If you look in views.views.inc, you'll notice an implementation of hook_field_views_data, which adds this relationship data for all entity reference fields. The issue is that it is only called for fields which are defined in config, i.e., the code is not called for any entity_reference fields added on any custom entity types or added using hook_entity_base_field_info.

Yeah, this gap between the way how we generate configurable fields and base fields is just sad.

+++ b/core/modules/views/src/EntityViewsData.php
@@ -374,7 +374,7 @@ protected function mapFieldDefinition($table, $field_name, FieldDefinitionInterf
     foreach ($field_column_mapping as $field_column_name => $schema_field_name) {
-      $views_field_name = ($multiple) ? $field_name . '__' . $field_column_name : $field_name;
+      $views_field_name = ($multiple) ? $field_name . '__' . $field_column_name : $schema_field_name;
       $table_data[$views_field_name] = $this->mapSingleFieldViewsData($table, $field_name, $field_definition_type, $field_column_name, $field_schema['columns'][$field_column_name]['type'], $first, $field_definition);

I could totally imagine that this is the right fix, but yeah we need some test coverage to ensure it happens.

Okay, I think I've found a more appropriate solution.

Kicking tests.

+++ b/core/modules/views/src/EntityViewsData.php
@@ -581,6 +581,15 @@ protected function processViewsDataForEntityReference($table, FieldDefinitionInt
+      if ($field_definition->getFieldStorageDefinition()->isMultiple()) {
+        $database_field = $field_definition->getName() . '_target_id';

Maybe use $field_definition->getFieldStorageDefinition()->getMainPropertyName() instead of hardcoding target_id?

Setting back to needs work for the test coverage.

#8 solves the problem for me.

Added $field_definition->getFieldStorageDefinition()->getMainPropertyName() as suggested in #10

Patch in #13 works for me. Thank you everyone for the work!

My test case:
Three entity types, A, B and C.
Entity type A has the following fields:
- entity reference field for B with a cardinality of 1
- entity reference field for C with unlimited cardinality

Create a view for A.
Add relationship to B.
Add a field with relationship to B.
This works both before and after patch.

Add relationship to C.
Add a field with relationship to C.
This fails before patch and works after patch.

Why the patch is only for fields with multiple values ?
I have the same problem with a single value field #2903687: Can't create referencing entities relationship on custom entity (See also #2895578: Views does not add reverse relationship data for entity_reference fields not defined in configuration)

Confirming Patch #13 addresses CARDINALITY_UNLIMITED reference id issue when custom entity is defined in the class vs type/bundle db configuration. Please add to core or document preferred method of defining custom BaseFieldDefinitions for view compatibility.

Marking as RTBC by @sdrong

Per #10 it still needs test coverage,

The patch doesn't align with the issue title here? It's not only multi cardinality fields that are an issue, any ER field that isn't defined in configuration is ignored by core_field_views_data() #2895578: Views does not add reverse relationship data for entity_reference fields not defined in configuration could be a duplicate or we could rename the issue title here?

I agree with @benjy, this patch doesn't do enough to fix the problem for single-value entity reference base fields. I think it's best to re title this issue and keep #2895578: Views does not add reverse relationship data for entity_reference fields not defined in configuration to do the other work.

We do have a views data unit test, but this looks like something that we would want to test with at least a kernel test. Is there a kernel test we could use to do this with or is a functional test sufficient?

+++ b/core/modules/views/src/EntityViewsData.php
@@ -581,6 +581,15 @@ protected function processViewsDataForEntityReference($table, FieldDefinitionInt
+        $views_field['filter']['field'] = $database_field;

Missing an option for $views_field['filter']['argument'] here. This will still throw an SQL error when using contextual filters.

This issue also applies to other non entity reference fields as well. For example I have an custom entity type with a file field. The views_views_data() function invokes hook_field_views_data but only for fields defined by a field_storage_config entity, so file_field_views_data() isn't called for my custom entity's file field, therefore the relationship isn't added.

I’m not quite sure what you mean by ‘non entity reference fields’ — isn’t a file field a type of entity reference field?

@joachim I guess you could argue that it is, but they're their own field type which is used as a prefix for hook_field_views_data() (e.g file_field_views_data()).

I believe I am encountering this issue.

The patch applies to 8.7.5 but does NOT fix the issue.

In my case I have a view that uses contextual filters to grab the user id.
It then creates a relationship to a entity reference field on that user for organizations and from that org entity it grabs a list of products referenced on the org entity.

The preview shows the proper list of products for a given user.

When I create an entity reference field that uses the view to populate itself the list is just organizations not the products.

The problem from the issue description was fixed in #2846614: Incorrect field name is used in views integration for multi-value base fields / Drupal 8.5.

#28 is about #2337515: Allow @FieldType to customize views data.
#32 sounds unrelated.