| Project: | Flag |
| Version: | 5.x-1.x-dev |
| Component: | Flag core |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
| Issue tags: | anonymous flagging |
Issue Summary
I've ALMOST got anonymous users working with flags in Drupal 5. As a guide, I used the D6 patch in comment #27 of #271582: Allow anonymous users to flag content however the Views - Flag integration code has changed significantly between d5 and d6... and I'm SOOO close but at wits end for not understanding how views magic works.
Basically, the problem is that for anonymous users the flagged items DO correctly show up in a view that filter's on User's Id, but the wrong link is getting inserted. The view is showing the flag_link for the 'flag' action when it should be showing the link for the 'unflag' action.
I know exactly where in the code its going wrong, but don't know how to adjust the views_tables definitions for flag_content:
The key is the comment inserted there aboute using the Ops to detect if the item is flagged or not. I need to somehow change this so it not only depends on uid field but also new sid field!
<?php
// $Id: flag.views.inc,v 1.1.2.5 2008/06/15 08:40:39 quicksketch Exp $
function flag_views_tables() {
global $user;
$flags = flag_get_flags();
foreach ($flags as $flag) {
/// other table stuff ....
$table = array(
'name' => 'flag_content',
'join' => array(
'left' => array(
'table' => 'node',
'field' => 'nid',
),
'right' => array(
'field' => 'content_id',
),
'extra' => array(
'fid' => $flag->fid,
'uid' => $flag->global ? 0 : $user->uid,
'sid' => $flag->global ? 0 : flag_get_sid($user), // Session API integration
// Note: since this is a LEFT JOIN, we also get records where
// uid is empty; that is, nodes which haven't been flagged.
// This is intentional, as we want to display the Ops field
// for unflagged nodes too.
// The Ops field handler utilizes uid being empty (NULL) to
// efficiently figure out whether or not a node is flagged.
),
),
'fields' => array(
'ops' => array(
'field' => 'uid',
'name' => t('Flag: Ops for @s', array('@s' => $flag->title)),
'help' => t('Display an AJAX link to flag, or unflag, the node. Note that the operation is made on behalf of the user who <em>browses the page</em> and not the user whose name happens to appear adjacent to the link.'),
'handler' => 'flag_field_handler_ops',
'query_handler' => 'flag_query_handler_ops',
'fid' => $flag->fid,
),
),
);
/// more stuff here....
}
return $tables;
}
?>It looks like only uid=X is getting executed as the "value" for the 'ops' field (flag_content_flag-name_ops). What (**i think**) happens is when Views calls the 'handler' it sends along a value (either uid or null) based on the execution of the filter. I need that value to also be based on sid as well as uid match.
I wish I knew more about whats going on here, but everything i've tried hasn't generated any change.
Anyone have a clue how I change the views table definition so that it 1) only still shows essentially the one filter in the admin interface, but to effectively sneak in the two comparisons for anonymous user (uid=0 AND sid=current session) ?
initial patch attached in first comment....
Comments
#1
initial patch for flag module v5.x-1.0-beta6
#2
So, I figured out how to detect if a flag is flagged after studying D6 implementation a bit further... The bad part is that it requires a separate database query. However, this is also the way it works in D6, so it is in effect simply a backport of existing functionality. The D6 version does in fact use some caching mechanism to get around multiple db hits.
I basically implemented a D5 version of the D6's Flag class's is_flagged() function. This second patch adds
function flag_is_flagged()<-- cached versionfunction _flag_is_flagged()<-- non-cached versionThis version should be working, but the disclaimer is that I haven't had a chance to test it for all use cases with views integrations. I've got a deadline on a project and suffice it to say It Works For Me in my current site's implementation. When I get some breathing room, I'll come back and do some further testing.
#3
this patch was created as an /update/ for existing flag module installations... If you apply my patch, be sure to:
1) install Session API
2) run update.php or else you'll get some sql errors expecting the new column 'sid' in the flag_content table.
Note also that if the update generates a warning message like the following, it appears to not have any negative effect...
#4
* fixed a problem with view handler only using the view's creator's (administrators) uid/sid pair.
#5
Hello,
I have a question : did you work on the beta6 version ?
I tried your patch, but it could only be applied on beta4, and it doesn't work, I had a lot of errors...
If you worked on this version, what did you change ?
I don't know Drupal enough to make my own change like that, so I ask you.
[Actually, I took a look at your patch, and I don't know why it doesn't work, that's why I ask you]
#6
@jrguitar21: That's really cool that you're getting so close! quicksketch posted a new patch in http://drupal.org/node/271582#comment-1279848 so, I'm going to mark this as postponed.
#7
Tagging
#8
RG:
Did you follow the instructions in comment #3 about running update to change the DB tables? I'm afraid I have no clue now which version I patched against. I think it was simply "dev" back in Feburary and not sure which betas existed at that point. Perhaps if you could copy some of the errors you were getting here it would also help.
Sorry for a really late reply here, its been a busy month :/
#9
With the 2.x branch moving forward and being targeted for Drupal 6/7, we're no longer working on the 1.x version or Drupal 5..