Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This comes from http://drupal.org/node/34496#comment-1338292
We need to write a configurable action for executing a given flag so that it can be added to the Trigger: After saving a new comment.
Comment | File | Size | Author |
---|---|---|---|
#13 | flag_better_triggers.patch | 12.38 KB | quicksketch |
#11 | flag_better_triggers.patch | 8.53 KB | quicksketch |
Comments
Comment #1
sirkitree CreditAttribution: sirkitree commentedComment #2
quicksketchI'm not interested in any further actions for Trigger to use. See my comment in #397458: Revamp mailing logic to leverage flag module.
Comment #3
sun@quicksketch: Even if this will make flagging (starring) issues on drupal.org reality? ;) :P
Couldn't we simply expose 1 "Flag the commented node" action for each flag in the system?
Comment #4
mitchell CreditAttribution: mitchell commented#298109: Rules integration already has this:
Also, here is an exported rule where I use this: http://drupalbin.com/8387
Comment #5
sirkitree CreditAttribution: sirkitree commentedAwesome! Thank you mitchell!
Comment #6
sunHm, Rules won't fly. IIRC, several "majors" of the community reviewed Rules module and the common feedback was "This bloated thing won't make it into D7." (again, AFAIK).
Comment #7
quicksketchRight, I agree. Rules is extremely heavy and I would never use it on my own sites.
A better approach would be for the d.o custom module to simply implement a hook_comment() and inform users that way. Another alternative is to build support into subscriptions/signup modules. But again, this functionality is very specific to these use-cases and Trigger really isn't suited to configure actions with a variety of conditions.
I chatted very briefly with dww at DrupalCon, he didn't think it would be troublesome to implement this functionality elsewhere for drupal.org.
Comment #8
dww@quicksketch: Maybe the issue hasn't been clearly explained yet. Here's the idea:
Whenever a user creates a post or adds a comment, it'd be nice to provide a configurable action that says "have the current user flag this node with flag X". I.e. when you post a comment on an issue, you should subscribe to it by default. Even with the suckiness of trigger, a configurable action should be all we need for this, since there are already triggers for new post and new comment, which is all we really need. Don't worry about sending emails, we'll deal with that otherwise. We could easily use hook_form_alter() and friends to add a "subscribe to this post" checkbox on node forms and comment forms for our specific use-case. I just thought it'd be nice to handle this in a general way.
Thoughts?
Comment #9
quicksketchOh! Well thanks dww for explaining the issue. We could almost use trigger for this. We could write a trigger action for "Flag this" and "Unflag this" and make it configurable for the flag that needs to be fired. Similar to how you can publish/unpublish nodes when a comment is posted.
However, this is where Trigger falls a bit short, we couldn't actually limit it to which content types the posting of comments should fire the Flag. This wouldn't be too bad, as long as the "Subscribe" flag applied only to the project_issue type. Otherwise Flag would start flagging any type on which the "Subscribe" flag is enabled on every comment.
So my end answer, yes if we make "Flag" and "Unflag" configurable action that has a single options for "Enabled flags", then I'd be fine with it. We could also take a short cut and automatically make non-configurable actions for each flag, e.g. "Flag with subscribe" and "Unflag with subscribe" or just simply "Subscribe" and "Unsubscribe" (using the Flag short labels).
Comment #10
dww@quicksketch: Yes, that's exactly the idea. And, the concept on d.o is that you could flag anything, not just issues, and have that show up in your tracker (and, if you wanted, your inbox). "+1 subscribe" is just as annoying in forums as the issue queue (although less prevalent). I think a configurable action makes more sense than a set of non-config actions (for each flag), especially since the # of different flags on a site could grow quite large. However, I don't care much either way -- whatever y'all think is best. I'm a relative noob to the world of flag, after all. ;) Thanks!
Comment #11
quicksketchOkay, totally going back on what I said earlier about "someone else can write it".
Here's a patch which makes Trigger/Actions support actually worthwhile. Now that I've seen workflow.module in use, I know it's apparently acceptable to completely flood the list of possible triggers. So this patch adds two triggers for every flag on the site "Flagged with [flag name]" and "Unflagged with [flag name]". That makes trigger integration much more useful (though still not really useful since there's no way to specify flag threshold).
But that doesn't actually affect what we really care about, which is the "action" side of things. This patch also provides a configurable action for "Flag (or unflag) a node". I also made matching actions for comments and users for completeness. So now we can setup a "node" action for "Flag this node" and configure it to "flag" with the "subscribe" flag. Then add that action to the "After saving a new comment" Trigger.
I totally haven't tested most of this functionality, considering how many combination of flag/unflag, flag name actions and node/user/comment triggers, there's a lot to test.
So.... now that this is possible. I still want us to ask, "should we really use it?" If this were my site I'd circumvent the need for it at all with a hook_comment().
Tada! Or we can load 200 lines of PHP, do 2 extra database queries, and run through 4 functions to get to the same call. Oh well. :P
Comment #12
dwwHa, good point. ;) On d.o we could either do that in drupalorg.module, or even perhaps in project_issue itself along with the other flag-specific integration. Definitely seems a lot cheaper than the alternative...
Comment #13
quicksketchI really didn't think I was going to commit this patch until I discovered that it has the excellent side-effect of making it so that you can trigger a flag when another flag reaches a threshold via the flag_actions.module, neat! So in other words I could set up a flag for "offensive", then a global flag for "needs_review". When 10 users have marked as offensive, the "needs_review" flag is triggered (which users don't usually have access to). The moderator reviews the content, then unflags as offensive if it's considered okay. Then more users can continue to mark offensive but it will never trigger the "needs_review" flag again! That's a neat trick.
So I committed this patch to the 2.x branch where we can continue to test out this functionality. I still think Trigger generally is not useful, but the additional capabilities that this gives flag_actions.module makes this patch worth including.
This updated patch contains a few changes to prevent namespace conflicts with flag_actions.
Comment #14
quicksketchComment #15
quicksketchDoh, right categories.