Closed (fixed)
Project:
User Relationships
Version:
7.x-1.x-dev
Component:
Views
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Nov 2012 at 10:40 UTC
Updated:
27 Aug 2013 at 11:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
franxo commentedIt happens to me as well
I think the mistake is the one indicated in http://drupal.org/node/1834500
What do you think?
Comment #2
djween commentedI think I am having the same or similar issue with:
User relationships: Status link (Status link)
in that the status link is:
user/REQUESTEE/relationship/%/remove
when it should be:
user/REQUESTER/relationship/%/remove
However, when I assign the REQUESTER relationship in this field:
(requester) User relationships: Status link (Status link)
the status link is correct:
user/REQUESTER/relationship/%/remove
But then all the friends (requestees) are output multiple times. I am using a distinct query and that doesn't help.
The requestees in the output of the view come out as such:
user/A/relationship/123/remove
user/A/relationship/456/remove
user/B/relationship/123/remove
user/B/relationship/456/remove
I have played with all the relationship and field settings but am stuck with what should be an easy view to put together.
Please help!
Thanks.
Comment #3
tjhart87 commentedMy suggestion was incorrect ... I too am having the same issue.
Comment #4
unlu-tv.org commentedIt happens to me as well....
Comment #5
pblissmt commentedI created a patch for this, It creates a new view handler for getting the status link from the point of view of the current user, essentially reversing the current function, and showing the text to say remove this requestor_id instead of requestee
So it doesn't say that you will remove the you when it should say the selected person that will be removed from the relationship
And it adjusts the view query to lock the relations it brings back to just the relation record for your relation to them, not all relations that person has which was breaking my view.
Hope this helps
Comment #6
ctrahey commentedI would like to provide some additional context & justification from when pblissmt & I discussed this:
Even though we thought at first that the included field handler was misbehaving, we decided ultimately that it was working as it was supposed to. Here is the rationale:
In views, we can/should think from left-to-right through our joins, with right-pointing arrows hinting at the "perspective" of our field handlers. In our case, we were building a view for a "user profile". So with the given that I am User "ctrahey" and I have a relationship to "pblissmt" (and he to I), when I am looking at the profile of pblissmt, the view looks like this:
pblissmt --(relationship)--> ctrahey
This explains why the confirmation message (when removing the relationship) prompted me with, "Are you sure you want to remove the relationship with ctrahey?". My first thought is, "Hey, I *am* ctrahey"... but in terms of how the view sees it, I was working from pblissmt's perspective. Thus, I think the view handler was working as it was supposed to.
We then decided it was useful to provide a field handler for the "implicit" relationship between the logged-in user and the user being inspected.
Comment #7
JvE commentedThis patch gives me:
Fatal error: Call to undefined method stdClass::build_join() in sites/all/modules/contrib/views/plugins/views_plugin_query_default.inc on line 1313I think the way the requester_id == current_user condition is added needs to be done differently.
Comment #8
JvE commentedComment #9
andypostThe cause of this bugs a typo in second part of handler
So no way to build link from requester side!!!
Marked as duplicate #1326476: Status Link in Views - Can Unfriend, but Can't Friend
Comment #10
Andre-BComment #11
berdirThanks, committed and pushed!
@Andre-B: When you set an issue to RTBC, please describe what and how you tested, otherwise there's not much meaning in an RTBC.
Comment #12
Andre-B@Berdir: I do a code review on all of the patches I RTBC or even add (see the other issues), as well as testing them locally and check if they solve the issue. Next I do some basic checks for the pages that have been modified and a simple 'friends' relationship - deeper testing should be done by the test cases that run anyways after each patch + needs review? am I wrong?
Comment #13
berdir@Andre-B: That's perfect. It's just that I don't know that you've done it when you post an empty comment and set it to RTBC. So just write a quick comment and say something similar to what you did now, that you did a code review and tested it manually.
Comment #14.0
(not verified) commentedUpdated issue summary.