I would think that this is the default out of the box for this module (I am confused why it is not). Furthermore, I am not sure this is possible based off of what I have seen so far in the SQL that is generated in Views.

I setup a relationship of child. Basically, I want a way for parent to find their child on a site and create a relationship with that child so that they can follow that child. Now, the parent has a relationship to the child (one way). I want to create a view for a parent that shows their content that the child (or multiple children) have created.

The problem that I have discovered is that the views addon module defaults to join the node.uid on the user_relationships.requester_id. I am confused as to why it does this. Could someone explain?? It seems kind of useless to me to show only content if the requester has some type of relationship.

The problem then is that I am now unable to create the view that I need without having two relationships. The one I have (from parent to child) and then back (from child to parent) to get a view of content. Here is the SQL from views that led me to this conclusion:

SELECT node.nid AS nid, 
node.title AS node_title, 
users_user_relationships__user_relationships.rtid AS users_user_relationships__user_relationships_rtid, users_user_relationships__user_relationships.updated_at AS users_user_relationships__user_relationships_updated_at 
FROM node node  
LEFT JOIN user_relationships user_relationships ON node.uid = user_relationships.requester_id 
LEFT JOIN users users_user_relationships ON user_relationships.requester_id = users_user_relationships.uid 
LEFT JOIN user_relationships users_user_relationships__user_relationships ON users_user_relationships.uid = users_user_relationships__user_relationships.requestee_id 
WHERE (users_user_relationships__user_relationships.approved = '1') AND (node.type in ('blog')) AND (users_user_relationships__user_relationships.requester_id = 1)

Notice the three LEFT JOINs in this statement. The first left join limits the request to the requester (in my case the parent). The next two left joins are the magic that would show the content the children created, but it only works if there is a relationship going both ways. The ultimate problem, in my opinion, is in the fact that the user_relationships table is joined with the node table on the requester_id. User views default join on the requestee_id and I am unclear why the decision was made to do these two type differently.

Anyways, if someone could explain to me why this decision was made or how to get around this problem then I would be very appreciative.

Comments

alex.k’s picture

alex.k commented

It's a valid question and good research. The problem is that there are two equally important links between two users (or the viewer and another user's content in your case) - initiator and receiver of the relationship. When I was writing Views integration I saw that, basically, only one column could be chosen to join user_relationships table to the user table. So I had to choose, and chose requester_id.

I remember looking for examples within existing Views integrations at that time, and not finding any good solution to a case where a table has more than one link to another table (two different foreign keys from the same table). The only way to offer both links would kill any hope of users making sense of an already obtuse setup of UR Views integration, that is, to come up with two aliases to user_relationship table, so that Views sees them as two different tables, each linked to users with a different column.

That's the reason, and in your case I would suggest using UR Implications to automatically set up a reverse "parent" relationship when a child relationship is created. A proper solution would be cool, though.

j_ten_man’s picture

j_ten_man commented

Interesting problem, and I understand now a bit better why you did this. I am not sure what the consequences of the following workaround would be, but my suggestion is this:

  //...user_relationship_views_views_data()
  $tables['user_relationships_node_requestee'] = $tables['user_relationships'];
  unset($tables['user_relationships_node_requestee']['table']['join']['user'], $tables['user_relationships_node_requestee']['table']['join']['user_relationship_types']);
  $tables['user_relationships_node_requestee']['table']['join']['node']['field'] = 'requestee_id';
  $tables['user_relationships_node_requestee']['table']['group'] = t('User relationships - Requestee Node');
  return $tables;

Basically, copy the node relationship over, and now I can choose one or the other. I have not played around enough with all of the options to know what this will do exactly or if it is a good or bad idea. However, it does fix the issue that I am running up against. I will look into the UR Implications module as well.

alex.k’s picture

alex.k commented

Yep, that's the "two table" workaround. There should be one more key in that array to tell which physical table you're referring to, IIRC.

The only consequence should be that it's very confusing when one doesn't know which to choose :)

YK85’s picture

YK85 commented

+1 subscribing

May I kindly ask if there has been any further development?

I'm currently looking for customized views for User Relationships and having a lot of trouble.
Looking in the queue it seems like it is a continuing struggle the community is having.
Would appreciate any help and will definitely report back if I figure stuff out =)

robby.smith’s picture

robby.smith commented

subscribing

mrf’s picture

mrf commented
Status: Active » Closed (duplicate)

Marking this as a duplicate of #455792: default "user_relationships_content" View doesn't work for one-way relationships feel free to re-open if there is something else going on here.

nikkubhai’s picture

nikkubhai commented

In my case its not working even for two way relationships