Problem/Motivation

\Drupal\state_machine\Plugin\views\filter\State::getBundles takes two approaches to getting the bundles to retrieve workflows for. Both of these have some fragility:

  1. Bundle key is a filter: this is prone to conflicts, probably with high probability. type is a common bundle key, if you have a view with entity A and entity B, both with bundle key type, with a bundle filter on A and a state filter on B, you will get an invalid list of bundles.
  2. Fall back to EntityFieldManagerInterface::getFieldMap for field bundles: This is fragile due to a core bug (or arguable a poorly defined API which contrib makes use of) #3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields resulting in the field map not being accurate.

Proposed resolution

  1. Could be solved by doing some checking against the filter handlers to be more accurate, essentially looping over them.
  2. It is safer here to use EntityTypeBundleInfoInterface::getBundleInfo. It does result in creating more workflows than is perhaps necessary, but if performance is an issue, we could always cache the results of Status::getValueOptions, with appropriate tags that should be fairly reliable with changes elsewhere.

User interface changes

Should be none.

API changes

A change to the injected services - not sure if that is going to be an issue for BC. I know my short term solution to this has been to extend, but then I would be expecting to drop that when this is fixed. Not sure what other use case there would be for extending this.

Data model changes

None.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

andrewbelcher created an issue. See original summary.

matteodem’s picture

StatusFileSize
new842 bytes

Experienced the same error with an entity key conflict between Order and OrderItem. Following patch makes it work locally, as a temporary solution.

a.dmitriiev’s picture

+1 to have the fix. Relying on the filter values with bundle key causes the problem with order items and order states in the same view. They both have bundle key as type and having them together in one view leads to problems, because State filter tries to load non-existing order types (because it takes order item types).

khiminrm’s picture

I've also faced with the same issue. I had views based on commerce_invoice entity type and with relation to orders. I had filter for invoice type (bundle) and tried to add exposed filter by the order state. The code of the State filter tried to get bundle of the commerce_invoice filter and to get states for not existing commerce_order bundle - from the value of the commerce_invoice bundle filter.

I've created patch which works for my case and hope will work for others.

khiminrm’s picture

Status: Active » Needs review

  • jsacksick committed 2e59e5b7 on 8.x-1.x authored by khiminrm
    Issue #3045520 by khiminrm: Views filter getBundles is fragile.
    
jsacksick’s picture

Status: Needs review » Fixed

Committed, thanks!

TomTech made their first commit to this issue’s fork.

tomtech’s picture

Status: Fixed » Needs review

Added additional handling in the case where multiple type filters may be present, so we can't rely on the filter key.

This also handles multiple type filters and does not treat a filter with the not in operator the same as the in operator.

  • jsacksick committed 7bb0ef9f on 8.x-1.x authored by TomTech
    Issue #3045520 by khiminrm, jsacksick: Views filter getBundles is...
jsacksick’s picture

Status: Needs review » Fixed

Trusting you on this, committed!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.