provide Views reverse relationships automatically for entity base fields

Not sure how to handle the situation when referenced table is not described to views yet, so just added isset check.

Lets see what testbot thinks.

Right, I think this way is more obvious

Silly, this is how it supposed to be...

I've tested this patch (#24) on a simple view I have. It's a view on one entity with view_bulk_operations checkboxes. When I add a reverse entity reference field to the view and select a single row for a VBO action, VBO acts as if all rows in the view were selected.

@joachim Thank you for the great work on this. Is getting all tests passing the only thing remaining?

I was able to use the important parts of your patch in a custom class, until this patch is committed to core. Attaching it here in case anyone else finds it useful in the interim.

Thanks for your work on this @joachim.

The patch at #34 will also apply cleanly to 8.6.x, and I'm getting usable reverse relationships to an entityreference base field on a custom entity. In my case neither that entity nor the referenced entity are revisionable.

Re-running tests.

Only patch reroll

Adapted this code into CommerceEntityViewsData, so that Commerce and its contribs get reverse relationships:
#3096916: Generate reverse relationships for base entity references
Other contribs, feel free to steal it, for until the core patch lands :)

EDIT: This is now a pat of the Entity API contrib module, from version 1.0. just use Drupal\entity\EntityViewsData in your entity type annotation.

This does not appear to work for me using ECK entities, but whether that's an ECK problem or a limitation of the patch I do not know yet.

#42 doesn't apply to 8.7.11 :(

For 8.8

Patch #42 and #48 are breaking the site for me with this error:

PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function Drupal\views\EntityViewsData::mapSingleFieldViewsData(), 7 passed in /var/core/www/modules/contrib/commerce/src/CommerceEntityViewsData.php on line 204 and exactly 9 expected in /var/core/www/core/modules/views/src/EntityViewsData.php:460

This patch breaks backwards compatibility by changing the function definition for mapSingleFieldViewsData() and removing the return parameter, so the entire file must be rewritten.

I see in #45 that similar work has been done in Commerce, however, this does not create the reverse relationship from an order to a subscription with that order as its initial order (an entity_reference field). And I cannot apply this patch because it breaks Commerce views integration.

I see this as a Drupal core bug rather than a Commerce bug. For a base field definition that is an entity reference, these views relationships and reverse relationships should be created automatically.

Upload a D9 compatible patch. Just updated two lines.

I faced the following error to noticed the patch was not d9 compatible :
Fatal error: Uncaught Error: Call to a member function getDefinition() on null in /app/web/core/modules/views/src/EntityViewsData.php:611

For anyone using a patch before 54 on a Drupal 8 site, perhaps using composer-patches, when you upgrade to Drupal 9 you will get an error stacktrace that starts like this:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getDefinition() on null in Drupal\views\EntityViewsData->processViewsDataForEntityReference() (line 611 of core/modules/views/src/EntityViewsData.php).

Putting this here in the hopes the search engines will index it and it will help other people running into this problem :)

Applies at Drupal 9.2.7 with -11 lines offset:

web$ wget https://www.drupal.org/files/issues/2021-08-24/provide-views-reverse-relationships-automatically-for-entity-base-fields-2706431-54.patch
--2021-11-01 16:19:12--  https://www.drupal.org/files/issues/2021-08-24/provide-views-reverse-relationships-automatically-for-entity-base-fields-2706431-54.patch
Resolving www.drupal.org (www.drupal.org)... 151.101.14.217
Connecting to www.drupal.org (www.drupal.org)|151.101.14.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14331 (14K) [text/plain]
Saving to: 'provide-views-reverse-relationships-automatically-for-entity-base-fields-2706431-54.patch'
provide-views-reverse-relationships-automatically-for 100%[===============>]  14.00K  --.-KB/s    in 0.004s
2021-11-01 16:19:13 (3.70 MB/s) - 'provide-views-reverse-relationships-automatically-for-entity-base-fields-2706431-54.patch' saved [14331/14331]

/web$ git apply -v provide-views-reverse-relationships-automatically-for-entity-base-fields-2706431-54.patch
Checking patch core/modules/views/src/EntityViewsData.php...
Hunk #1 succeeded at 301 (offset -11 lines).
Hunk #2 succeeded at 339 (offset -11 lines).
Hunk #3 succeeded at 401 (offset -11 lines).
Hunk #4 succeeded at 418 (offset -11 lines).
Hunk #5 succeeded at 429 (offset -11 lines).
Hunk #6 succeeded at 443 (offset -11 lines).
Hunk #7 succeeded at 550 (offset -11 lines).
Hunk #8 succeeded at 569 (offset -11 lines).
Hunk #9 succeeded at 595 (offset -11 lines).
Hunk #10 succeeded at 607 (offset -11 lines).
Hunk #11 succeeded at 729 (offset -11 lines).
Hunk #12 succeeded at 751 (offset -11 lines).
Applied patch core/modules/views/src/EntityViewsData.php cleanly.

Attached patch works for Drupal 9.3, there were some minor deprecation issues which I fixed.

Applies and works on a clean Drupal 9.3.

Does not apply to 9.4.x-dev

Added reroll of patch #59 on Drupal 9.4.x.

Quick Review:

@sch4lly you may have unintentionally uploaded the wrong patch, but the patch #59 is identical to the patch #54 even the index hash code is the same.

diff --git a/core/modules/views/src/EntityViewsData.php b/core/modules/views/src/EntityViewsData.php
index f8d8ed6301..f6f7221168 100644

Regarding #62. Thank's @ravi.shankar for the re-roll. :)

Just two notes:

1. You forgot to remove a space between the @param tags here:
   

   @@ -473,10 +482,10 @@ protected function mapFieldDefinition($table, $field_name, FieldDefinitionInterf
       * @param \Drupal\Core\Field\FieldDefinitionInterface $field_definition
       *   The field definition.
       *
   -   * @return array
   -   *   The modified views data field definition.
   +   * @param array $data
   +   *   A reference to the views data.

2. I noticed a that the biggest difference between patch #54 and #62 is at the end of function EntityViewsData::mapFieldDefinition. I Don't know if the change is correct or not, (I didn't analyze deeper), but I'm pointing it out, so someone else can do a deeper review.

Thanks @andregp.

Added reroll of patch #59 for Drupal 9.4.x. and I have removed space as said in comment # 63.1.

Added reroll diff as well.

Please ignore patch #62.

Resolved CSpell errors & added an interdiff.

Keeping it in NW as it requires tests.

When used with Commerce module patch #65 causes errors described in #50. Also field_name parameter in mapSingleFieldViewsData() seems unused.

As mentioned in #69, the patch #65 causes 2 errors many times for me in dblog:

1. Undefined variable: table_data in Drupal\views\EntityViewsData->mapFieldDefinition() (line 457 of core/modules/views/src/EntityViewsData.php)



The $table_data variable is not defined before foreach.

2. Invalid argument supplied for foreach() in Drupal\Component\Utility\NestedArray::mergeDeepArray() (line 327 of core/lib/Drupal/Component/Utility/NestedArray.php)



The method mapSingleFieldViewsData() is used as argument for NestedArray::mergeDeep() in mapFieldDefinition(), but it returns nothing.

Just a note that "Build Successful" is not a pass. The patch is failing badly and will likely need a reroll for 9.5

@lkacenja and I have attached a patch that works on Drupal 9.4 and 9.5.

Fixed Drupal CS issue of patch #72.

The test fail for patch #75 is

Drupal\Tests\aggregator\Functional\Views\Handler\HandlerAggregatorTest::testHandlers
Undefined array key "entity revision"

We probably need to make sure we are adding the entity revision key to our relationship array.

Rerolling patch #75 for Drupal 10.1.x.

I believe the test fail is due to #3004300: EntityViewsData fails to set 'entity revision' in the table data for an entity's revision table.

Did not review.

But was previously tagged for tests which still appear to be needed

Also issue summary should follow standard template.

Anyone wanting to work on the missing test should look at EntityReferenceRelationshipTest (which tests the forward and reverse relationship for configured fields) and EntityViewsDataTest (which tests the forward relationship for base fields, and is where the test for the reverse should go).

Currently EntityViewsDataTest::testBaseTableFields() has:

    $relationship = $data['entity_test']['user_id']['relationship'];
    $this->assertEquals('users_field_data', $relationship['base']);
    $this->assertEquals('uid', $relationship['base field']);

We probably need to add to this:

    $user_data = $this->entityTypeManager->getHandler('user', 'views_data')->getViewsData();
    $this->assertEquals('entity_reverse', $views_data['reverse__entity_test__user_id']['relationship']['id']);
   ... etc

Played this and it looks it needs much more work.

After installing with the commerce module enabled, i get:
Uncaught PHP Exception ArgumentCountError: "Too few arguments to function Drupal\views\EntityViewsData::mapSingleFieldViewsData(), 7 passed in /home/merlin/Code-Incubator/site-c4c-dev/web/modules/contrib/commerce/src/CommerceEntityViewsData.php on line 220 and exactly 8 expected" at /home/merlin/Code-Incubator/site-c4c-dev/web/core/modules/views/src/EntityViewsData.php line 483

Which is because a $data ("all views data") arg was added to mapSingleFieldViewsData method.
- 1) This is a BC break.
- 2) Looking over the code, my gut feeling is that adding this arg makes complex code even more complex and should be done differently.

Rerolling patch #80 for Drupal 11