Payment list is broken

I have the same problem.

Thanks for reporting this problem! Can you provide the exact steps needed to reproduce this problem on a clear installation of Drupal with Payment, including exact versions of the software you used

In the meantime you can disable that view and use the standard payment list builder on that page instead (just disable the view and go back to admin/content/payment).

Try to access the Payment from My Account menu
.../user/1/payment

So the problem is the relationship handler 'current_payment_status_delta'.

It does the join correctly, but it adds a field to the select query for the view as follows:

SELECT payment.id AS id,


  payment__payment_statuses_payment.id AS payment__payment_statuses_payment_id


FROM {payment} payment
LEFT JOIN {payment__payment_statuses} payment__payment_statuses_payment ON payment.current_payment_status_delta = payment__payment_statuses_payment.delta

payment__payment_statuses_payment.id AS payment__payment_statuses_payment_id

should be

payment__payment_statuses_payment.entity_id AS payment__payment_statuses_payment_id

My views data skills are not sufficient to know how to fix this....

OK so I have narrowed this down to a fairly critical issue.

Currently a bunch of views relationships are broken for payment. Basically all relationships to payment sub tables: payment__line_items and payment__payment_statuses.

This is because views adds fields to all entity tables in a view, including relationships:

Drupal\views\Plugin\views\query\Sql::query near line 1147

    // Make sure each entity table has the base field added so that the
    // entities can be loaded.
    $entity_information = $this->getEntityTableInfo();
    if ($entity_information) {
      $params = array();
      if ($groupby) {
        // Handle grouping, by retrieving the minimum entity_id.
        $params = array(
          'function' => 'min',
        );
      }

      foreach ($entity_information as $entity_type_id => $info) {
        $entity_type = \Drupal::entityManager()->getDefinition($info['entity_type']);
        $base_field = !$info['revision'] ? $entity_type->getKey('id') : $entity_type->getKey('revision');
        $this->addField($info['alias'], $base_field, '', $params);
      }
    }

From the above code, because the views relationships for payment statuses and line items are from the payment base entity, the line $base_field = !$info['revision'] ? $entity_type->getKey('id') : $entity_type->getKey('revision'); Always chooses the base field id since id is the identifier for payment entities.

Since however the tables being joined to are created from plugin fields on the payment entity (ie. LineItemItem and PaymentStatusItem) extending PluginCollectionItem, their id columns are always named entity_id, not id like payment. With normal base fields, there would just be extra columns on the entity table, but in this case there are extra tables created for each field, which id columns different to the id column on the base entity.

Has someone else working with the plugin module already come up with a solution for this? Seems like it is pretty likely to crop up...

Surely there is some way of telling views that these joins are to field tables and not

Thank you for researching this, and sharing those details with us!

I'm moving this to the Plugin module, and I'm lowering the priority to normal, as these problems do not crash sites or corrupt data.

Multivalue fields always live in their own tables, so that's by design. I quickly checked the plugin field type class, and couldn't immediately see anything wrong with the schema or field property definitions that can cause this problem.

I'm working on making Payment's Travis CI builds pass, so we can test any patches as soon as possible. I'll be at Drupal North and the Drupal Dev Days over the next week, so we can also look at this in person if anyone's around.

The Travis CI builds pass again, so PRs can be submitted.

The query fails on unknown column payment__payment_statuses_payment.id, but the payment__payment_statuses_payment table doesn't even exist. The payment status field's table is payment__payment_statuses.

I'm a bit eager :p

It looks like this is a Payment issue after all. I looked at the Views data integration to look for clues and it's a bit of an old mess. I am working on #2633800: Add a Views filter for plugin fields now, and perhaps we can remove lots of Views integration code from Payment by relying on Plugin's Views integration instead, which is newer and has decent test coverage.

Yup! I agree that this is an issue with how views and plugin fields play together. Thanks for the issue link.

Ahh the issue you linked to is about plugin fields providing views data for filters. I think what this issue needs is plugin fields providing views data for relationships...

Ok, so I found the solution. It is actually a core bug and the ongoing issue is here #2729325: EntityViewsData adds entity type to multi-value base tables, conflicts with QueryPluginBase::getEntityTableInfo. The patch works, just needs to pass tests.

That fix was committed some days ago, and will make its way into Drupal 8.1.8 and 8.2.0. Once 8.1.8 has been released, we must remove the patch from ./travis-ci/build/composer.json, and update the version constraint of the Drupal core dependency to ^8.1.8.