Rules: Allow for grabbing flagged entities by user other than nodes.

Good call!

Just a few things:

+++ b/flag.rules.inc
@@ -229,38 +206,64 @@ function flag_rules_action_info() {
+    $label = isset($entity_info['label']) ? $entity_info['label'] : $type;

I have a hunch that the entity label must always be set -- check the docs for the info hook.

+++ b/flag.rules.inc
@@ -292,6 +295,9 @@ function flag_rules_action_info() {
+  // For backward compatibility sake. This was the original name of the 'fetch node by user'.
+  $items['flag_fetch_entity_by_user'] = $items['flag_fetch_node_by_user'];
+  unset($items['flag_fetch_node_by_user']);

Nice touch! (Shame this didn't get spotted till after I released 3.0, as we could have just changed it and not bothered with backwards compatibility...)

But can we keep the 'node' item in, even if it's a duplicate, to encourage the better behaviour?

> I dont see having a duplicate dropdown item as desirable. It would most likely get called out as a bug later.

Call the backward compatibility one something like 'Node (legacy)' so they look different in the dropdown. I do see your point about the duplicate being taken for a bug in future, but the node one being called 'entity' will be taken as a WTF in future :)

> I figured someone had a reason for doing it before.

Maybe. Or maybe whoever it was didn't read the docs ;) Let's drop it.

Thanks generalredneck. Tested this patch and it works as designed. As much as I hate seeing duplicate behaviors (Fetch node flagged by user & Fetch node flagged by user (Legacy), I guess it is something that we will have to stick in there for compatibility purposes. Hoping to commit this to the dev version asap. @Joachim, hope you confer.

> As much as I hate seeing duplicate behaviors (Fetch node flagged by user & Fetch node flagged by user (Legacy), I guess it is something that we will have to stick in there for compatibility purposes

Indeed! But once this is in, let's file a follow-up to remove the legacy one for D8.

Patch looks good to me. Go ahead and commit :)

> do an upgrade on rules

Digging around in rules.install may reveal some existing upgrade procedures for this sort of thing.

Yup, I always try to attribute commits, but good idea to remind our new maintainer :)

@Shabana: I've probably already told you, but I suggest you use Dreditor, which makes making commit messages very easy, including attributing them to the primary author of the patch.

@generalredneck, You will definitely get your name attributed. You did the work, you should get the kudos.

> Digging around in rules.install may reveal some existing upgrade procedures for this sort of thing.

Yeah, I will do some digging around and hopefully, we can find an easier solution for the D8 upgrade for the 'Legacy' issue.

@joachim, Yup, I have been using Dreditor since you gave me the heads-up on it. It really makes life a lot easier when it comes to checking patches and creating commit messages, which were always a pain for me. Thanks for that tip.

Committed to 7.x-3.x branch.

Congrats!

It looks like your forgot to give the git attribution though -- using dreditor, you need to click on one of the names it pops up beneath the proposed commit message, and then use the entire git command on the command line to make that user the author of the commit (as well as being credited in the commit message).

Doh! Is it too late or can I still change it?

We can't re-do commits once they're pushed to d.org git unfortunately!

Yikes! @generalredneck, really sorry. Definitely won't happen again. Will make sure you get your proper dues in the next commit for the issue: https://drupal.org/node/2054927.

I don't know if it was this patch or another of the changes to our Rules support, but something has broken -- any chance someone could take a look at #2077017: Most Recent Update (7.x-3.1) Broke Rules Configurations?