I'm testing Flag on a client site, and if I set a user to be able to reset abuse flags,

print flag_create_link('abuse_node', $node->nid);

it no longer allows them to flag content. They only get the "reset flags" link.

Reset flags 

#10 flag-abuse-remove-reset.patch8.44 KBezra-g
Members fund testing for the Drupal project. Drupal Association Learn more


tanjerine’s picture

subscribing. i've been wondering about this too.

Barry: I'm not sure if this will work for you, but I disabled all the default flags and re-created them and I am now seeing the 'flag content' links.

BarryHoggard’s picture

Thanks for the info, but I'm concerned about what happens with upgrades if it's not working now without deleting and re-creating things.

quicksketch’s picture

Project: Flag » Flag Abuse
Version: 6.x-2.0-beta5 » 6.x-2.x-dev

Sounds like this should have been filed in the Flag Abuse queue.

Thomas_Zahreddin’s picture

Version: 6.x-2.x-dev » 6.x-2.0-rc1

same here, complex site with many modules:

flags work, but not flag_abuse:

only for users the flag-link is visible after creating the flag manualy as #1 suggests.

But for the admin-users the the Reset -> Abuse is not shown.

ezra-g’s picture

I'm experiencing this issue with 7.x-2.x dev as well.

ryank76’s picture

Getting this for 6.x-2.0-rc1

ezra-g’s picture

This appears to be related to

 * Implements hook_preprocess_flag().
 * Here we change our flag event/action to 'reset'.
function flag_abuse_preprocess_flag(&$vars) {
  // Ensure the user has permissions and this is an abuse flag.
  if (user_access('reset abuse flags') && flag_abuse_is_abuse_flag($vars['flag']->name)) {
    $vars['action'] = 'reset';
    $vars['link_text'] = t('Reset flags');
    $vars['link_title'] = t('Remove all flags on this content');

It seems we'd want to provide an *additional* link to reset all flags rather than overriding the existing link to flag content.

ezra-g’s picture

Title: Users with "reset abuse flags" permission don't get the "flag abuse" links » All 'Flag abuse' flags rewritten to reset flags for users with reset flags perm

Marked #1530214: In views node flag abuse shows Reset flags instead of Flag abuse link as a duplicate.

I think we should consider removing the reset functionality (since it appears to not work in its own right) and file an issue for bringing it back in.

ezra-g’s picture

Version: 6.x-2.0-rc1 » 7.x-2.x-dev
ezra-g’s picture

Priority: Normal » Major
8.44 KB

The "reset all flags on this item" feature appears to be based on #571100: Add "reset" action and hooks to Flag (now fixed), though that functionality in Flag.module lacks a UI per #823314: Flag Reset Links/UI.

The default flag exports in flag_abuse module attempt to make use of this functionality by adding a 'reset' to the list of events:

    'events' => array(
      0 => 'flag',
      1 => 'unflag',
      2 => 'reset',

They appear to also set Flag properties that aren't yet exposed by the Flag UI:

    'reset_short' => 'Reset flags',
    'reset_long' => 'Reset all flags on this content',
    'reset_confirmation' => 'Are you sure you want to reset all flags on this content?',
    'status' => FALSE,

It appears that Flag abuse attempts to reset all "flag this content" link for its flag types with reset links but

A) That removes the ability for users with the "reset flags" permission to flag content
B) It appears to do so in a way that's not recognized by flag.

I'll try to evaluate the work necessary to fix the reset implementation versus just removing it from Flag abuse and letting it be re-introduced as a feature request.

I rolled a quick patch to remove the reset functionality for the time being, which should restore the fundamental functionality of Flag Abuse for users who lost it due to this issue.

Leaving as "active" rather than "needs review" pending an assessment of fixing the reset functionality rather than removing it.

ezra-g’s picture

Title: All 'Flag abuse' flags rewritten to reset flags for users with reset flags perm » Remove "Reset" functionality
Status: Active » Needs review

Given that the reset functionality:

- Is causing bug in the module that is major to critical
- Requires non-trivial refactoring in order to be implemented in a scalable way (#1074242: Re-introduce whitelisted content) and that this refactoring is similar in scope to a re-implementation anyway

I propose we commit the patch in #10, remove the "reset" functionality and re-introduce it as part of #1074242.

sirkitree’s picture

agreed, though I don't have time atm to review the actual code.

ezra-g’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

MustangGB’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev
Status: Closed (fixed) » Patch (to be ported)