Using the 7.x-3.x-dev is causing problems with rules

Flag and Un flag works ok except when having a Rule with the event:
A node has been unflagged, under "flag name"

When I try to un flag the node I get the following error message:
RulesEvaluationException: Argument flagging is missing. in RulesPlugin->setUpState() (line 648 of /Applications/MAMP/htdocs/mysite/sites/all/modules/rules/includes/rules.core.inc).

When I disable the rule involved, unflagging works fine

This happens with 7.x-3.x-dev or 7.x-2.x-dev with any of the flag fields patches

Note: Rules with: A node has been flagged, under "flag name" events work ok
Here's the rule causing the error

{ "rules_open_case_poll" : {
    "LABEL" : "Open Case Poll",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules", "flag" ],
    "ON" : [ "flag_unflagged_test" ],
    "DO" : [ { "drupal_message" : { "message" : "Poll opened" } } ]
  }
}
CommentFileSizeAuthor
#9 1719942.9.flag_.rules-event-flagging-variable.patch1.17 KBjoachim
#6 1719942.flag_.rules-event-flagging-variable.patch686 bytesjoachim

Comments

joachim’s picture

joachim commented
Status: Active » Postponed (maintainer needs more info)

Thanks for pasting the rule!

However, when I import this I get a notice 'Unknown event "flag_unflagged_test"'.

joachim’s picture

joachim commented

Aha, got it now. The '_test' part is the machine name of the flag.

joachim’s picture

joachim commented
Status: Postponed (maintainer needs more info) » Active

Ok, so who knows how Rules gets its arguments in? Because I can't actually see that in our code.

joachim’s picture

joachim commented

*sigh*

I hate working with Rules.

  if (module_exists('rules')) {
    $event_name = ($action == 'flag' ? 'flag_flagged_' : 'flag_unflagged_') . $flag->name;
    // We only support flags on entities.
    if (entity_get_info($flag->entity_type)) {
      $variables = array(
        'flag' => $flag,
        'flagged_' . $flag->entity_type => $entity_id,
        'flagging_user' => $account,
        'flagging' => $flag->get_flagging($entity_id,$account->uid),
      );
      dsm($variables);
      rules_invoke_event_by_args($event_name, $variables);
    }

This is probably because there is no longer a flagging entity when we are unflagging. We'd need to check the workflow, and hook_flag() should be documented to this effect.

In 2.x, we had this:

      $variables = array(
        'flag' => $flag,
        'flagged_' . $flag->content_type => $content_id, 
        'flagging_user' => $account,
      );
      rules_invoke_event_by_args($event_name, $variables);

Hence the flagging entity was added as a parameter when flaggings became entities (and so not in the great rename issue, ha!)

So we have two possible fixes:

A. Drop the flagging parameter.
B. Tell Rules that it's an optional parameter that isn't always there.

B seems the better fix to me but I have no idea how to do that. Any ideas?

joachim’s picture

joachim commented

#1720148: optional variables in hook_rules_event_info().

joachim’s picture

joachim commented
Status: Active » Needs review
StatusFileSize
new 1719942.flag_.rules-event-flagging-variable.patch686 bytes

Even simpler than marking it optional, in fact.

Could you try this patch please?

Orange Studio’s picture

Orange Studio commented

Success
After applying the patch the error has gone away and now unflagging works as expected with rules.
Thanks for your help Joachim.

joachim’s picture

joachim commented

I've going to leave this a bit as technically we shouldn't pass in the flagging variable when we unflag. But #1720402: split hook_flag() and kill $op will fix that if we do that one first :)

joachim’s picture

joachim commented
Status: Needs review » Fixed
StatusFileSize
new 1719942.9.flag_.rules-event-flagging-variable.patch1.17 KB

Issue #1719942 by joachim: Fixed RulesEvaluationException when unflagging Rules event is invoked.

Committed this slightly modified patch.

Sort of a follow-on: #1720180: hook_flag_unflag() should be invoked before the flagging is deleted.

Status: Fixed » Closed (fixed)

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