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:
- Bundle key is a filter: this is prone to conflicts, probably with high probability.
typeis a common bundle key, if you have a view with entity A and entity B, both with bundle keytype, with a bundle filter on A and a state filter on B, you will get an invalid list of bundles. - Fall back to
EntityFieldManagerInterface::getFieldMapfor 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
- Could be solved by doing some checking against the filter handlers to be more accurate, essentially looping over them.
- 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 ofStatus::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.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | state_machine-avoid-entity-key-conflict-order-state-3045520-4.patch | 712 bytes | khiminrm |
| #2 | avoid_entity_key_conflict_order_state.patch | 842 bytes | matteodem |
Issue fork state_machine-3045520
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
Comment #2
matteodem commentedExperienced the same error with an entity key conflict between Order and OrderItem. Following patch makes it work locally, as a temporary solution.
Comment #3
a.dmitriiev commented+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).
Comment #4
khiminrm commentedI'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.
Comment #5
khiminrm commentedComment #7
jsacksick commentedCommitted, thanks!
Comment #10
tomtech commentedAdded 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 inoperator the same as theinoperator.Comment #12
jsacksick commentedTrusting you on this, committed!