Actual case I ran into:
I have:
- a commerce product entity.
- a node type that serves as product display and as such has a product_reference field with unlimited values (being references to commerce products).
Given a rules action context in which I have available a commerce-product, I want to:
- fetch the product display(s) that display the commerce product.
So I create an action "Fetch entity by property"":
- entity type:node
- property: the product_reference field
- value: commerce-product
(- limit result count: 1)
Result:
- Validation error message "The data type of the configured argument does not match the parameter's value requirement."
Expected:
I expect that it would be valid to search entities by multi-valued properties and that in this case Rules will search for entities that have the given value in 1 of the property values. Therefore, I consider this a bug.
Working towards a solution:
- In method RulesPlugin::checkParameterSettings() I commented out the line (after the call to RulesData::typesMatch()):
throw new RulesIntegrityException(t("The data type of the configured argument does not match the parameter's %name requirement.", array('%name' => $name)), array($this, 'parameter', $name));
This obviously prevents the validation message from appearing, and will thus save the action. But does the action subsequently work? yes:
- entity_property_query() will correctly build and execute the EFQ and return the first node (due to the limit = 1) that refers to the commerce-product. So it looks like the error is in RulesData::typesMatch() being too restrictive in this case.
Proposed Solution:
- Adapt RulesData::typesMatch() to return true when $var_info has 'type' = 'list<{type}>' and $param_info has 'type' = '{type}'.
I will gladly write a patch, but want to know:
- is what I expect correct and thus can this indeed be considered bug?
- RulesData::typesMatch() is called in many more places, so just adding some code to always match list<{type}> to {type} seems a bit to loose. Is this indeed to loose and if so, how to solve it in this specific case?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | rules_action_fetch_entity_by-2475097-2.patch | 1.2 KB | fietserwin |
Comments
Comment #1
fietserwinDiving further into the code, I think that a solution is to be found in changing the function rules_action_entity_query_info_alter(), as that will allow us to bend the rules specifically for the "Fetch entity by property" action.
The attached patch does so and seems to work fine for me, i.e. i do no longer get an error message and do have access to the fetched_entity in later actions (thus the entity is fetched correctly).
Comment #2
fietserwinWrong line-endings and better use of negative values in substr(). New patch
Comment #4
freelockThis patch seems appropriate to fix the problem, and works for me on a commerce site.
I verified that the field type expected now also lists commerce product in addition to list of commerce products, which is the behavior I expect. Marking RTBC...
Comment #5
vasikei can confirm both the issue and the patch solution (#2) for a multiple valued product reference field.
Comment #7
fagoThanks, committed!