Originally reported by: @mhavelant

Gitlab PR: https://github.com/brainsum/gdpr/pull/8

modules/gdp_fields/src/Plugin/Deriver/TypedDataEntityRelationshipReverseDeriver.php

<?php
      // Provide the entity type.
      $derivative_id = $data_type_id . ':' . $property_name;
      if (isset($this->derivatives[$derivative_id])) {
?>

This throws notices and results in a "function call on null" error down the line, as 'target_entity_type' doesn't exist in some cases.

TypedDataEntityRelationshipReverseDeriver::generateDerivativeDefinition() calls the parent generateDerivativeDefinition, which doesn't seem to properly populate the derivatives array. Also, generateDerivativeDefinition() runs twice, and the second time the target_entity_type is there as one would expect.

Paths where I'm getting the exception:

  • /admin/reports/fields/gdpr-fields
  • /admin/gdpr/tasks/1
  • /user/1/gdpr-request/gdpr_sar
CommentFileSizeAuthor
#4 2018-05-08 09_31_54-Used in GDPR _ Contacts Events.png17.01 KByanniboi
#4 2018-05-08 09_31_08-Task 1 _ Contacts Events.png18.91 KByanniboi
#2 gdpr-2971267-2.patch732 bytesyanniboi

Comments

yanniboi created an issue. See original summary.

yanniboi’s picture

yanniboi commented
Status: Active » Needs review
StatusFileSize
new gdpr-2971267-2.patch732 bytes

I discovered another patch that I had been using on my environment (provided by another module) that fixes an issue in ctools which is described here: #2866323: Fatal error on empty entity reference relationship.

yanniboi’s picture

yanniboi commented
Issue summary: View changes
yanniboi’s picture

yanniboi commented
Status: Needs review » Needs work
StatusFileSize
new 2018-05-08 09_31_08-Task 1 _ Contacts Events.png18.91 KB
new 2018-05-08 09_31_54-Used in GDPR _ Contacts Events.png17.01 KB

OK, no, turns out my hunch is wrong. That patch was already incorporated in the other patch that composer.json requires.

So I am stuggling to recreate this error. My environment is as follows:

Drupal core: 8.5.3
GDPR: 8.x-1.x branch
Ctools: 3.0.0 with 2951267-2.patch

Some user fields configured as below

Field config page:

Field config

SARS Task View:

Task view

baluertl’s picture

baluertl
he/him
Primary language Hungarian
Location Budapest 🇪🇺
commented
Title: Ctools entity relationship deriver error. » Ctools entity relationship deriver error
mhavelant’s picture

mhavelant commented

I still get this error.
Setup: Minimal profile install of 8.5.3 running in the lates wodby/docker4drupal environment (5.0.6)

This setup gives no errors when the only additionally enabled modules are gdpr, gdpr_dump and gdpr_fields.

However, enabling either of the remaining sub-modules gdpr_tasks or gdpr_consent, the exception occurs.
Every backtrace shows that the $data_type_id is an entity_revision (e.g "entity_revision:message:consent_agreement_accepted").

If I add this inside the if (isset($this->derivatives[$derivative_id])) { condition

        if (\strpos($data_type_id, 'entity_revision:') !== FALSE) {
          dpm($data_type_id, 'data');
          return;
        }

then the exception goes away and dpm shows only entity_revision items.

The full list of these after reinstalling my local site with the standard profile and enabling all of our gdpr modules (+ these: automated_cron config update adminimal_admin_toolbar devel kint field_ui):

  • entity_revision:block_content:basic (displayed 2x)
  • entity_revision:contact_message:feedback (displayed 2x)
  • entity_revision:contact_message:personal (displayed 2x)
  • entity_revision:message:consent_agreement_accepted (displayed 2x)
  • entity_revision:node:article (displayed 4x)
  • entity_revision:node:page (displayed 4x)
  • entity_revision:shortcut:default (displayed 1x)
  • entity_revision:taxonomy_term:tags (displayed 2x)
  • entity_revision:gdpr_task:gdpr_remove (displayed 4x)
  • entity_revision:gdpr_task:gdpr_sar (displayed 4x)

  • mhavelant committed bd1749f on 8.x-1.x 
    #2971267 by yanniboi: Browser test to check field list UI.
yanniboi’s picture

yanniboi commented

Wow, great job! I can't believe it took us this long to be able to recreate this :P

I have updated the test to show the error and fixed it by excluding entity_revision relationships. We can choose to support this in the future, but only if we find scenarios that justify it.

yanniboi’s picture

yanniboi commented
Status: Needs work » Fixed

Pushed commit https://www.drupal.org/commitlog/commit/91358/bc64a056c0db7cdc283764d231... to 8.x-1.x.

baluertl’s picture

baluertl
he/him
Primary language Hungarian
Location Budapest 🇪🇺
commented
Status: Fixed » Closed (fixed)

Moving issue state manually from Fixed 🠂 to Closed (fixed) in the hope that issue queue gets cleaner a bit.