Create message: "Login to [flagname] [nodetitle]"

excuse me if this has been brought up before

Always speak your mind. This module certainly has flaws.

[...] but the view seems to be the hard part.

I've started a bookpage explaining this:

Having a "Please login to flag" link. (You should use the "views 1.x" instructions.)

Let me know whether it works for you.

Yes Sir! I was just about to do a work-around in hook links to do this. Glad I found this!

People who are using images as the bookmark text won't be able to benefit from this feature. So I thought of a better one.

What about displaying the image to all users and if the user has inadequate permissions redirecting to the login/register page , or displaying a message telling the user the must log in to to use this.

We could also do the same for the original problem in this post? What do you think?

Hi, I have followed the steps for views 1 and renaming the 'bookmarks' part to my flag name in the function but its not showing when a user is not logged in, anyone having the same problem?

@dropchew,

I have followed the steps for views 1 and renaming the 'bookmarks' part to my flag name in the function but [...]

Let's suppose you take the code shown on that handbook page and paste it as-is into your template.php. Will it work for your *bookmarks* flag?

Hi mofiffie

Nope, I tried using the default created 'bookmarks' flag and copy the code as it is into template.php but it doesn't work, same for the flag that I created myself..there's no 'login to flag' on node or teaser....its working fine after logging in....

there's no 'login to flag' on node or teaser

Ah. Is your view of a "teaser / full" type?

The views recipe in the handbook is good only for views that are styled as tables or fields. When the data is styled as "teaser / full", it's Drupal itself that prints the nodes (not Views), and in this case you need to use the instructions under "Instructions for node.tpl.php".

Oh ic , but how do I do it in node.tpl.php? In your recipe its still stated as [TODO]? If it too much trouble I can wait until you release the docu : ) Thanks!

base on http://drupal.org/node/302623 I just created the module.

Yes, it works fine. but not generic. how if I have new/edit the flag, I have to edit the module. my module is for flag "signup_clinics"
Furthermore, it does not follow the "Placing a flag link on a page".

Hope someone can come up with more generic modules and added features

I'm considering a "You must login" option, which may be enabled if a user cannot flag unless logged in. Something just like:

[x] Show login to flag message for anonymous users

Unfortunately this would almost certainly require a text field to go with it, because the verb might change, i.e:

- You must Login or Register to flag content
- You must Login or Register to favorite content

So the textbox would probably look something like:

Login to flag message:
[ You must <a href="@login">Login</a> or <a href="@register">Register</a> to flag content ]

Which we could then run through t() with @login/@register as hard-code URLs that are available.

Anyway I'm not super-keen on that approach because of the additional complexity it adds to the admin form. When such functionality could be added fairly easily in the theme layer or by a contrib module, I'm not sure it's worth the overhead.

Thanks najibx for sharing your code, that's probably the general approach I'd use also.

I am new to the flag API, but as I could see there is no way for a contrib module to extend the core flags with new settings, so I implemented this against the existing core. Extended the default settings method, and added configuration forms.

There might be one problem with enabling this: because now anonymous are not excluded completely we can't just return on the flag_link when !$user->uid, so it might have performance impacts. Providing the patch nevertheless, maybe there is a way to do it via contrib.

Also using the placeholders and t() like this is not the best solution, because then we aren't using l(). This means that the links won't use the destination and might break sites where the site is located in a subfolder (this i tested locally).

The patch uses hardcoded words for login and register, maybe another UI element would be needed for this, but i leave it for now so I can get some feedback.

Changed version, because patch is against the 1.x branch.

New features are not being added to the 1.x version. If wanting this feature added to Flag, please provide a 2.x patch and I'll review it.

I figured a way to do this in a contributed module for 2.x, but it is not possible for 1.x because of the reasons listed in #13.

When such functionality could be added fairly easily in the theme layer or by a contrib module, I'm not sure it's worth the overhead.

Simply think .. which site would NOT want that feature? I thinks its fairly 95/5 for the "I want that" guys :D

XiaN, can't Custom Links do this work? Please let us know.

I might, but i can't see why this should be done via an 3rd party module. Isn't that strictly a flags feature o_O

Hi,

I think this is a must have feature. Is there a solution to this I tried flag anonymous module but it does not work in views.
Thanks,
Prerna

So a quick recap:

- There's now a special-purpose module to add this particular functionality: http://drupal.org/project/flag_anon
- And there's a handbook page on how to do this in a custom module: http://drupal.org/node/302623

I'm still interested in adding this directly to the module. @snufkin's patch in #13 looks pretty good but could use a reroll for the 2.x branch (as well as D7).

The patch also introduces an interesting syntax which we could possibly use to solve #1256012: Allow html text instead of plain link text.

I'd also like to see #1291670: Provide a live (iFrame) preview of various flag texts in action introduced to help with the addition of new textfields.

Here's a simple integration of flag_anon into flag; should be very similar to what snuffkin did in #13 for the 3.x branch. Would be nice to get this into flag core and eliminate the need for flag_anon, which has been left behind and doesn't integrate out-of-the-box with flag 3.x.

Is there a particular problem with having the anonymous login link functionality in a separate module? If it's just that flag_anon is no longer being maintainer, have you considered asking to take it over? I'm sure if snufkin doesn't have time to work on this module any more he'd be happy to hand it over.

Considering that Flags forbids anonymous user_access unless Session API is installed, it is difficult to allow for this type of modification in an external module. flag_anon is limited by this (see http://drupal.org/node/1033726); otherwise I'd be up to help maintain it.

Aside from architectural considerations, I think there is enough evidence to consider this a common use case. Seeing as this functionality doesn't interfere with other Flags operations (it simply adds a benign default behavior), I don't think there's a whole lot to lose.

+++ b/includes/flag/flag_flag.inc
@@ -424,8 +426,9 @@ class flag_flag {
-    // Anonymous user can't use this system unless Session API is installed.
-    if ($account->uid == 0 && !module_exists('session_api')) {
+		// Anonymous user can't use this system unless Session API is installed
+		// or an anonymous link has been designated.
+    if ($account->uid == 0 && !module_exists('session_api') && empty($this->anon_display)) {
       return FALSE;
     }

I'm not very happy with this bit conceptually (also, whitespace errors but that's moot). We're granting the anon user access to the flag here. And then much much later in the flow, in the templare_preprocess, we change the link text and URL.

That means that in between the two pieces of code, there's a ton of stuff where the anon user has access even though they shouldn't. Anything else that steps into that flow (other modules on alter hooks, other link types etc) things they see access has been granted. For that matter, have you tested this with other link types? What about the 'edit checkbox on form' option? If you granted anon users to post comments, for instance, they would be granted access to checkbox because you've granted $flag->access().

So that seems flawed to me.

I would much rather the whole of this happen in flag_link():

    if (!$flag->access($entity_id) && (!$flag->is_flagged($entity_id) || !$flag->access($entity_id, 'flag'))) {
      // User has no permission to use this flag or flag does not apply to this
      // entity. The link is not skipped if the user has "flag" access but
      // not "unflag" access (this way the unflag denied message is shown).
      continue;
        // **** Here give the user a chance to log in if anon and setting allows it.
    }

And if that is your only point of action, then that could be done in a contrib module that does its own hook_entity_view().

Agreed, exposing the other flag endpoints to anonymous users isn't acceptable.

However, it seems to me that using hook_entity_view will prevent rendering of flags that are displayed individually (say, as a panel pane or in a view). That's my only reservation, but I think if ctools integration was committed this wouldn't be an issue. I'll look into it some more when I get some free time.

I modified a little two files to simulate how could this feature work.

This first alterations on flag.module use a fixed variable that should be converted into a configurable property of any flag:

function flag_create_link($flag_name, $entity_id, $variables = array()) {
  $flag = flag_get_flag($flag_name);
  if (!$flag) {
    // Flag does not exist.
    return;
  }

  $display_anyway = TRUE; // display a not active flag - an empty link - with a popup inviting anonymous to register

  if (!$flag->access($entity_id) && (!$flag->is_flagged($entity_id) || !$flag->access($entity_id, 'flag'))) {
    // User has no permission to use this flag.
    if ($display_anyway) {
      $action = 'unauthorized';
    }
    else {
      return;
    }
  }
  else {
    $action = $flag->is_flagged($entity_id) ? 'unflag' : 'flag';
  }
  return $flag->theme($action, $entity_id, $variables);
}

And this last alterations on flag.tpl.php change template variables which should be done in a preprocess function:

// preprocess link element
if ($action == 'unauthorized') {
  $link_href = '#';
  $message_text = t('You need to be registered to use this feature');
} 

This is doing the trick for us in our latest project. But we know we stepped into maintenance hell since D7 branch is closed to new features unless they are backports from D8.

Hoping it is the case for this one.

Cheers.