If you create a user flag and try to use "User is flagged" as a condition in a rule an error is thrown:
Notice: Trying to get property of non-object in flag_rules_condition_flagged() (line 399 of /Users/creynder/Dropbox/Work/Research/Drupal/drupal-7.x/sites/all/modules/flag/flag.rules.inc).
And the rule action is not executed.

The error is thrown in the flag_rules_condition_flagged method.
After a little debugging I found out the the 3rd parameter ($account) does not receive a user object, but an array containing 2 keys:
flag and user:select. See att. for dsm dump.
The 2nd parameter $entity however does receive the correct user object.

This rule condition does work as it should with node flags.

Files: 
CommentFileSizeAuthor
#12 2015-05-15 16-31-59.png74.97 KBstBorchert
#10 condition_flagged_empty_account-1610172-10.patch514 bytesstBorchert
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es).
[ View ]
#6 1610172-6.patch477 bytesShabana Blackborder
PASSED: [[SimpleTest]]: [MySQL] 254 pass(es).
[ View ]
Screen shot 2012-05-31 at 11.01.14.png26.81 KBcreynders

Comments

tbenice’s picture

having the same issue.

cpritz’s picture

Version:7.x-2.0-beta6» 7.x-2.0-beta7

same for me

cpritz’s picture

I changed the line 399
from: return $flag->is_flagged($flag->get_content_id($entity), $account->uid); in return $flag->is_flagged($flag->get_content_id($entity), $account);.
Idon't know if this is the right way, but it works for me.

joachim’s picture

Any chance you could post that as a patch please?

joachim’s picture

Version:7.x-2.0-beta7» 7.x-3.x-dev
Issue tags:+needs backport to 7.x-2.x

Upping version; will need backport.

Shabana Blackborder’s picture

StatusFileSize
new477 bytes
PASSED: [[SimpleTest]]: [MySQL] 254 pass(es).
[ View ]

Patch against version 7.x-3.x is submitted below.

Shabana Blackborder’s picture

Status:Active» Fixed
joachim’s picture

Status:Fixed» Needs review

Thanks for the patch!

Setting to 'needs review' so other users know this needs trying out.

Shabana Blackborder’s picture

For some reason, I cannot replicate this problem without the patch. Anyone else getting this error still?

stBorchert’s picture

Issue summary:View changes
StatusFileSize
new514 bytes
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es).
[ View ]

Hey.
This seems still valid as we are getting this error reproducible on a commerce-site after anonymous users finalize the checkout.

The problem is, $account is "0" in flag_rules_condition_flagged() so we need to check this first. $flag->is_flagged() requires a user ID so handing a full user object to it will obviously break later.

joachim’s picture

> The problem is, $account is "0" in flag_rules_condition_flagged() so we need to check this first. $flag->is_flagged() requires a user ID so handing a full user object to it will obviously break later.

Can you explain a bit more please?

Are you saying that the Rules callback sometimes gets an $account object, and sometimes a number 0?

stBorchert’s picture

StatusFileSize
new74.97 KB

Are you saying that the Rules callback sometimes gets an $account object, and sometimes a number 0?

Jup, exactly. As far as I remember this happens only for anonymous users on finalizing the checkout process.
Without the patch you will get an error in flag_rules_condition_flagged() since $account is not an always object.

We had a rule setting the status of orders flagged with "Order paid" to "completed". The problem is caused by a condition that checks if the order is flagged (see attached picture).

joachim’s picture

> As far as I remember this happens only for anonymous users on finalizing the checkout process.

ONLY when finalizing the checkout process? Have you tried for anon users at other times? Because if you mean that it's only at that time, that smells like a bug in Commerce...