Had to debug this for some default rules in Commerce Checkout where I'm having to load a user by the e-mail address of an order ($order->mail). The first issue I ran into was that when trying to load a user with the "Fetch entity by property" action, I could not select the mail property of the order to load it by. In fact, all I could select were existing users... the reason being rules_action_entity_query_info_alter() was setting my value parameter to only accept values of the same type as the entity I was trying to load:

/**
 * Info alteration callback for the entity query action.
 */
function rules_action_entity_query_info_alter(&$element_info, RulesAbstractPlugin $element) {
  $element->settings += array('type' => NULL);
  $element_info['parameter']['value']['type'] = $element->settings['type'];
  $element_info['provides']['entity_fetched']['type'] = 'list<' . $element->settings['type'] . '>';
}

Removing the value type adjustment solved the problem for me.

However, in the course of this, I found as well that the evaluation of this action calls the entity_property_query() function and then always uses array_keys() on the return value. The problem is that function can return NULL if you're trying to fetch an entity via a property that doesn't specify a query callback. This was causing a nice red fatal error. My solution was simply to check the type in the action callback on return:

/**
 * Action: Query entities.
 */
function rules_action_entity_query($type, $property, $value, $limit) {
  $return = entity_property_query($type, $property, $value, $limit);
  return array('entity_fetched' => !empty($return) ? array_values($return) : array());
}

The alternative would be to adjust entity_property_query() so it returns an empty array whether there weren't any entities available or it couldn't find a query callback. I suppose you could also just wrap the $return = ... line in an if().

These are both one-liners that I didn't think needed a patch, but I can roll one if you need to review that way.

CommentFileSizeAuthor
#2 rules_entity_query.patch2.63 KBfago

Comments

rszrama’s picture

Component: Rules Core » Rules Engine
Status: Active » Needs review

I suppose this needs review.

fago’s picture

StatusFileSize
new2.63 KB

Indeed. As the return value is fixed in the entity API now, it remains the first problem.

@patch: yep, rolling patches is always great as it lets the test bot run.

I rolled a patch, which fixes the alter info callback. I've also added in improvements, i.e. an options list callbacks for the property & updated the info of the value property.

Still the form of this action definitely needs work, as we also need to reload the form after the property has been selected (Now you'll have to save and enter it again to see the updated form). But we can care about that in a follow-up issue.

Also, when testing this I noted the data selector doesn't work properly for lists. See #1047296: Improve the Data selector UX and fix it for lists.

hexabinaer’s picture

Sorry - no, the patch didn't fix the problem. Or maybe I just misunderstood this thread ...

I have a content type which contains a date field. "Entity has field" sounded like a good condition to start with (aiming at unpublishing nodes later on, but that's a different story). "Data selector" contains 2 selectors: "site:current-user" and ">site:current-user ..." the latter of which is not even selectable.
BUT in the Value field I see all my custom fields listed. Only that none of these applies to user ...

Doesn't look like the intended behavior to me. Am I wrong?

fago’s picture

Status: Needs review » Fixed

ad #3: Sry, I'm not able to follow you. Anyway, as said even with #2 the UI is still not complete.

I decided to just go ahead and commit #2, as it's an improvement anyway. Let's handle everything else in follow-up issues.

fago’s picture

rszrama’s picture

Just stopping by to say that I don't hit the problems I experienced before after this update.

Status: Fixed » Closed (fixed)

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