flag_get_user_flags() uses wrong slots

Looks good to me.

I just had a look into this function. It has more bugs. I'll investigate this later this week.

OK, here's the patch.

We have three versions: D61, D62, D7. So three patches (I have one for D5 too).

Wrong slots

The code looks for the cache in the wrong slot, so the cache isn't used (espacially for D62 and D7: so $flag->is_flagged() doesn't use the cahce!).

Documentation mismatch

The other problem is wrong documentation. It states that the return value (when no content id is given) is:

[nid] => [name] => (fid => [fid], uid => [uid] nid => [nid], timestamp => [timestamp])

whereas it's actually:

[name] => [nid] => (fid => [fid], uid => [uid] nid => [nid], timestamp => [timestamp])

So which version is the intended behaviour? Acording to this historic 'Views Bookmark' commit the documentation is right. But somewehre along the way we inadvertently switched to the second version. (We already have code in 'flag.activity.inc' that accepts this version, so it seems we're bound to stay with it.)

The documentation should say "content_id", not "nid"; I'll fix it before I commit.

(Here's the patch for D5 in case I accidentally delete it.)

This isn't 'minor'.

The implication of this bug is that $flag->is_flagged(), on Flag-2.x, doesn't use the PHP cache.

Nate, are you fine with this patch? It also fixes a D7 bug ("$account->uid" instead of "$uid").

Don't bother applying and committing my patches: just approve them and I'll do the rest.

I'm glad you aren't webchick as she'd insist on a test (which is a very good thing, especially for this issue, but a single Drupal test takes ages to run (because of the setting up of the DB), and therefore to code).

Yep, take it away mooffie. Thanks again!

Committed.
http://drupal.org/cvs?commit=411358
http://drupal.org/cvs?commit=411360
http://drupal.org/cvs?commit=411356
http://drupal.org/cvs?commit=411354