Make permanent nature of reset flags optional

In my situation, implementing a forum, this request is vital for using Flag Abuse and Flag modules all together.

Manos
http://websynergy.gr/

+1 subscribing

+1

+1 We too have a site where we are concerned about 'reset' giving the content creator free reign to do whatever he/she wants with the content after it's been 'ok'd.

Imagine this scenario. A malicious user registers 10 accounts from different IP addresses over a few weeks. Once ready, he creates some innocuous posts, and then chooses one and flags it with many of the accounts. An administrator arrives, sees the content to be innocuous, and resets the flag. A week later, the user edits his content and replaces it with spammy links. Legitimate users cannot use the flagging system to alert admins that the content is abusive now.

Also quite possible in the case of account theft, zombie computers, and probably countless other methods of usurping users' control over their own content.

I'd love to see a patch for this as well. I spent a lot of time coming up with a solution that involved a lot of changes to Flag module (@see #478490: Reset event for Flag) which would make flag actions generalized enough to include something like 'reset' along with it's built-in actions of 'flag' and 'unflag' but it was shot down. What we did get however, was a new function in Flag 2.x called flag_reset_flag which we're now using.

If someone could come up with a solution to this flag always saying 'reset', I'd certainly support putting it into the module.

I guess I kinda read this wrong - I thought the issue was the link always saying 'reset' for anyone else - that's a different issue. This issue is about not being able to flag something after it has been reset, and this access restriction should be optional. Totally agree. It should also probably be an option each time the flag is reset.

hello sirkitree,

Yes its a totally different issue.

So do you have any suggestion of how we could proceed to solving this?

The permanent nature is it a functionality of flag abuse or the flag module?
I haven't look into the code yet but I should really solve this because the release of a forum using the flash abuse is due soon and it is vital to be able to re-flag a comment.

Manos
http://websynergy.gr/

Sure, check out the implementation of hook_flag_access(). It checks for a variable that is set when flags are reset (@see flag_abuse_flag). This automatically assumes that we want to set this variable every time a flag is reset on something. So we need to place a check there.

I would suggest making all of the reset flags a confirmation form and alter that form to have a checkbox that ask if this reset should be permanent or not. If it's supposed to be permanent, then we want to set this variable. else not.

+1 for this feature.

If we use a second flag to prevent future flagging it seems like we can solve multiple problems. This idea is also mentioned here #593784: Use 2 flags, report + ignore report instead of reset.

Using the confirmation form for unflagging abuse we can add an option for users with the appropriate permission to flag the node or comment with an "ignore abuse flag" (or whatever we want to call it). Then using hook_flag_access we can check for the presence of an ignore flag to decide whether to display the flag link. The abuse flags themselves would only need to display their normal text, which would resolve the issue noted in #5. The ignored state would be saved as a flag, resolving the issue with using the variables table to save reset data currently. And most relevant to this thread, the ignore flag would be optional at the time of unflagging abuse flags and only available to users with permission.

Does anyone see any problems with this approach?

A patch is attached that implements what I suggested in #10. It's functional, but I haven't tested extensively, so there are likely to be issues. It also doesn't take into account an upgrade path from using the variables table to the new flag. It should also probably provide a default view for ignored content. So there is still more to do, but it should be ready for feedback.

Using another flag for this purpose seems like overkill and ads more code than I'm willing to commit or maintain.

It also makes this a bit harder for the 7.x version where we have arbitrary flags.

I think a more sustainable approach to this would be a separate table that records if a particular node, comment or user has been 'ignored', and then check against that instead of another flag.

It's actually not much more code for the module itself, an additional ten lines or so. The rest is just default flags which Flags generates for us anyway. I guess I don't see the maintenance concerns. I actually see it from the opposite perspective. Using another flag allows less code and less maintenance than a separate table overall. Flags provides Views integration, as well as the ability to pre-emptively ignore certain content just by adding the ignore flag link for admin users. The only downside I see is the increased clutter in the Flags admin interface.

I haven't seen an explanation for the benefit of making arbitrary abuse flags, so I can't comment on that.

Any chance on having this patch for the D7 version, thanks

+1

What are the chances of having this patch in the incoming D7 release? Any?

+ 1

I have managed to remove the "one time flagging" but the reset button is not working well. You need to press the reset button several times to remove the flags.

I commented out this line in modules/flag_abuse/flag_abuse.module :

 /**
 * Implements hook_flag_access().
 */
function flag_abuse_flag_access($flag, $content_id, $action, $account) {
  if (flag_abuse_is_abuse_flag($flag->name)) {
    // Check to see if this flag has already been reset.
    ///if (variable_get($flag->name . '-' . $content_id, FALSE)) {
    ///  return FALSE;
    //}
  }
}

Hello people,

There is a better way to flag abusive content. Just use the normal flag module and add a "Rule" to reset the flags. Watch my video on how to flag offensive content using flags, rules and views. No need to code anything! Super easy and clean.

http://www.youtube.com/p/1A89955CCEB73A09

I was running into the same problem, I don't want the reset to be a permanent approval. As a quick workaround, I hacked the module (using version 6.x-2.x-dev from 2011-Feb-25), commenting out line 75 in flag_abuse.module so the function flag_abuse_flag() looks like this:

function flag_abuse_flag($event, $flag, $content_id, $account) {
  // permmission check instead of a role
  if (user_access('reset abuse flags', $account)) {
    // is this one of our abuse flags
    // @todo: should be dynamic
    if (in_array($flag->name, array('abuse_node', 'abuse_comment', 'abuse_user'))) {
      // remove all flags on this content
      $rows = flag_reset_flag($flag, $content_id);
      if ($rows) {
        // This user actually flags the content as well, so it may confuse the
        // user if they reset what they thought was one flag and we report two.
        $rows--;
        drupal_set_message(t('Reset !rows flags.', array('!rows' => $rows)));
        //variable_set($flag->name.'-'.$content_id, TRUE); // This line commented out so it is not stored permanently that this content has been reset.
      }
    }
  }
}

If you apply this hack to an existing installation, you will also need to delete all previously stored flag abuse variables (they look like 'abuse_node-123' => 'b:1;') from the variables table.

Hope that helps anyone.

The fix/hack in #19 works for me but I don't have time to do a proper patch right now.

It would need to be a configurable option per flag, defaulting to the current functionality.

I'm closing this ticket. Since the reset function has been removed from the code. The entire reset process needs to be rethought and/or rebuilt and patching the code is no longer meaningful, see https://drupal.org/node/1194566

Also, of relevance - https://drupal.org/node/823314

I really thing resetting should be part of the flag module.