provide Views reverse relationships automatically for entity base fields

Rerolling patch #75 for Drupal 10.1.x.

The last submitted patch, 80: 2706431-80.patch, failed testing. View results →

I believe the test fail is due to 🐛 EntityViewsData fails to set 'entity revision' in the table data for an entity's revision table Needs review .

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.

Agreed, the BC break needs fixing, as clearly other code is calling this.

(We probably need our BC policy to get real and state that generic entity handlers are public API, because everyone already treats them as such.)

> - 2) Looking over the code, my gut feeling is that adding this arg makes complex code even more complex and should be done differently.

I'm not sure how!

The nature of a reverse entity reference field is that we need to add data to ANOTHER table from the one for the current field -- it needs to go on the table for the reference field's target entity.

And the way the methods in this class work is that there is a helper method for each field type.

Therefore, the field type helper method, processViewsDataForEntityReference() in this case, needs access to the whole of the Views data, not just for the field's table.

In the meantime, I've converted the most recent patch to an MR, rebased on 11.x.

The UI texts aren't clear when the host and target entity type are the same, as with taxonomy parent field:

> “Taxonomy term using parent” — “Relate each Taxonomy term with a parent set to the taxonomy term.

Needs a rewrite.

I've had an idea for a clean way to do this. We would need get 📌 Allow @FieldType to customize views data Needs work in, and then the classes that provide Views data for each field type can implement two methods:

- one to add field data for the field table, with &$field_data as a param
- one to allow the class to add data ANYWHERE, with &$data as a param -- most field types would not need to use this