Closed (outdated)
Project:
Flag
Version:
7.x-3.x-dev
Component:
Views integration
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Jun 2009 at 06:28 UTC
Updated:
18 Aug 2025 at 14:09 UTC
Jump to comment: Most recent
Comments
Comment #1
quicksketchThis is similar to the handbook page for listing unflagged content at http://drupal.org/node/299335, but after tinkering with this for a good 20 minutes I can't figure out how to tell Views what I want (or indeed how to form a query in SQL that I can translate to Views). I think this should be possible but I'm having trouble figuring it out.
Comment #2
quicksketchOkay, well I found the problem within Views, and it does seem that this is currently not possible.
Views can generate a query such as (when nid = 349):
The key part is that Views adds the argument as "(flag_content_users.content_id = 349)" in the WHERE clause. In order to get the results you want, we need to have the filter on the JOIN, not in the WHERE statement:
I'll have to take a look at #371432: Exposing the flaggings table: Alternative Views support and see if this would overcome this Views limitation.
Comment #3
quicksketchWell #371432: Exposing the flaggings table: Alternative Views support won't help with this problem either. After talking with merlinofchaos about this problem, it seems that the best (or perhaps only) way to correct this is to enhance the argument or relationship handler in Flag. It doesn't look like it should be that difficult, but you never know when we can get around to these sort of things, so you might need to hang tight or find a work-around in the mean time.
Comment #4
witzel commentedOK, thank you. I will try something else in the mean time.
Comment #5
witzel commentedHas someone found a solution for my problem yet?
Comment #6
quicksketchNope, no progress on this issue.
Comment #7
Drupaled-1 commentedHello,
Do we know if this has been resolved yet, possibly with drupal 7? I am in the same situation as witzel at the moment. :)
Thanks in advance
Comment #8
jeff.k commentedI too am looking for this functionality. Any one found a solution?
Comment #9
Drupaled-1 commentedI have tried in vain to implement a workaround to this.
If we do not have a fix yet, is there a possible workaround one can think of?
Comment #10
Barsoth commentedI currently work on this issue, too.
But there seems to be a general logical problem: If you create a view with users who have not flagged content there will be an OR-connection among all flaggable nodes of the specified type. In my opinion this is supposed to be an AND-connection.
For example: There is a node type "Issue" which can be flagged by a user as "subscribed". Now you render a view showing all users who did not set the flag "subscribed" on any node of type "Issue".
The result: If a user ever has flagged an issue he / she will disappear from this list. So you actually get a list of users who have never flagged any content of the specified type.
So for your sports team this means that every member who has ever canceled a training will never show up in the participant's list for any other trainings.
More useful (at least for my use case) would be a list of users who have not flagged all nodes of a specific type.
Unfortunately I have no clue how to help you out or how to apply such a view.
Comment #11
Drupaled-1 commentedThank you for attempting this as well Barsoth.
Perhaps a fix for the way the module works will be implemented one day.
Comment #12
westie commentedI am encountering the same problem, I want to display a list of unread changes to each user. The users then click a flag to mark it as read which removes it from the "unread changes" view.
This all works but it suffers from a huge performance problem, when unticking the "Include only flagged content" checkbox the view starts to crawl with a Query execute time of 8712.13 ms! Flipping this round - with the box checked this takes only around 2-5ms...
Is something on my install causing this problem or is filtering by all unflagged content that expensive in the database? :(
Indexing flag_content > content_id made a improvement and brought this down to 2000ms..
Comment #13
areikiera commentedWould very much like this feature as well, if it's not already possible in D7. I've posted an issue for the D7 version here: #1504840: View of users who have not flagged a specific node
Comment #14
joachim commentedComment #15
joachim commentedThe problem and solution is well explained in comments 2 and 3 above.
I imagine you'd probably want this to come in the form of an argument, so you can make a view that works for any given node in the path.
That means you'd need a custom argument handler that's capable of interfering with the join that the relationship handler creates. That should be doable, should anyone have the time to have a go :)
Comment #16
kfurlotte commentedI have the exact same problem. I was thinking about finding a way to automatically flag a node for all users, upon node creation? Does anyone know if this would be possible? I looked into Rules a little for this one, but didn't find a way to flag the created now for all users.
Comment #17
joachim commented> I was thinking about finding a way to automatically flag a node for all users, upon node creation?
That's not the same problem at all.
Comment #18
kfurlotte commentedMy bad, I misunderstood the issue. I actually want to create a view showing all users who "did not" flag a certain node, but I don't need the other way around. Flagging node for all users would actually fix my issue, but didn't find a way to do that.
I will post an issue somewhere else, sorry for the brain fart.
Comment #19
ITMonkey commentedI came here looking for an answer to the same question, but as it seems to not yet be possible here is a potential workaround for your situation which I have employed for my Intranet. I have used your scenario for ease of following.
Please note that this is NOT a suitable workaround for situations where users are created regularly and/or without admin approval.
Create a new flag called attending in addition to the one called cancelled.
Authenticated users should have the rights to flag or unflag ONLY the cancelled flag.
Admin (or whatever role has the rights to create the training node type) should have the right to flag and unflag both. Neither of the flags should be set to global.
Attach both flags to the training node type.
Next create a rule on the event 'A node has been flagged' and choose the flag attending.
For EACH user, create an Action with the settings Flag to check for: Attending, Node: Flagged node, User on behalf to flag: Switch to direct input mode and enter the UID (Now you know why this is only suitable for sites with a limited number of known users!), tick skip permission check again.
Create a second rule on the event 'A node has been flagged' and this time choose the flag cancelled.
Set the Action to Unflag a node and choose The flag to check for: cancelled, Node: Flagged node, User on whose behalf to flag: Flagging user, tick skip permission check again.
You are now free to create two views, one showing users who have the attending flag and the other for those with the cancelled flag. Then just tell whoever creates the training nodes to tick the attending box (I don't know if it's possible to default this to on?)
In truth this needs to be extended slightly to allow for someone to 'un-cancel' so add a filter on the first rule to only run when it is the (eg) admin user who does the flagging and then add a third rule which does the exact opposite of the second rule (But I don't need this in my situation as mine is for users to confirm that they have read something and I don't want them to be able to unread them anyway.
I hope this gives you what you need even if it is a bit cumbersome!
Comment #20
Robytfc commentedAny solution for this yet? Thanks
Comment #21
Florian K. commentedI have had the exact same problem. I believe there is still no "solution", but i found another workaround that might help.
First you need an attending view. This view displays all users that have flagged attending on a certain node. It is important that the UID is part of the resulting table (in my case the column is excluded from display).
Than you need a second view that displays users. No relationships. Just a table that shows the users the way you like it. Plus one contextual filter: UID.
Finally I wrote a little PHP Code that loads the "attending" view -> executes it -> reads all resulting users -> builds an SQL Query selecting every user that is not part of the previous result -> calls the second view to print the users from the SQL result
I displayed my canceled users in a block. So I simply inserted this PHP Code in a Block and showed it in the sidebar.
Done!
PHP Code
=================
Comment #22
ivnishDrupal 7 is EOL. No more new features will be added.