I am currently working with the flag_page module, which allows for flagging any path within Drupal. It prints a block for each page flag using the following code:

/**
 * Implementation of hook_block().
 */
function flag_page_block($op = 'list', $delta = 0, $edit = array()) {
  if ($op == 'list') {
    $blocks = array();
    $flags = flag_get_flags('page');
    foreach ($flags as $flag) {
      $blocks[$flag->name] = array(
        'info' => t('Flag page block for ') . $flag->title,
        'cache' => BLOCK_NO_CACHE);
    }
    return $blocks;
  }
  elseif ($op == 'view') {
    $block = array();
    $flag = flag_get_flag($delta);
    //Check if user hass access to flag
    if ($flag->user_access()) {
      $block['subject'] = $flag->title;
      $url = (isset($_GET['q'])) ? $_GET['q'] : variable_get('site_frontpage', 'node');
      $content_id = $flag->get_content_id($url);
      if ($content_id) {
        $block['content'] = flag_create_link($flag->name, $content_id);
      }
      else {
        $block['content'] = flag_create_lazy_page_link($flag->name);
      }
    }
    return $block;
  }
}

It is not using hook_link to print the flagging link and therefore flag_anon has no effect. It would be fantastic if flag_anon would instead work to return TRUE for $flag->user_access and then take over printing of the flag_link itself. I'd expect that this would work for all flag implementations.

Comments

snufkin’s picture

Status: Active » Postponed

I don't think that this can be done with the current implementation. In order to be able to do this flag anon would have to create a new flag type, overwriting the access handling. I understand the use case and I think it is a reasonable one, but the way flag API works this requires a major redesign for which I do not have the time right now.

snufkin’s picture

i did some more research, and the source of this issue is the following: access to both to perform a flagging action AND to view the flag itself is determined via $flag->access(). I could overwrite it using hook_flag_access and overwrite the output in a later stage (e.g. in a preprocess), but then the flagging action remains open, so for these flags anonymous users could abuse the flag callback. The only way around this is to separate the permissions to 'view' a flag and to 'flag' and 'unflag' them. This has to be resolved within flag module itself.

Another solution is to support flag_anon specifically in flag_page. If someone opens an issue there please link it in a followup post.

antonnavi’s picture

Status: Postponed » Closed (outdated)