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?

Comments

fietserwin’s picture

Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new1.24 KB

Diving 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).

fietserwin’s picture

StatusFileSize
new1.2 KB

Wrong line-endings and better use of negative values in substr(). New patch

The last submitted patch, 1: rules_action_fetch_entity_by-2475097-1.patch, failed testing.

freelock’s picture

Status: Needs review » Reviewed & tested by the community

This 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...

vasike’s picture

i can confirm both the issue and the patch solution (#2) for a multiple valued product reference field.

  • fago committed d90a4db on 7.x-2.x authored by fietserwin
    Issue #2475097 by fietserwin, freelock, vasike: Action "Fetch entity by...
fago’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, committed!

Status: Fixed » Closed (fixed)

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