Is it possible to create a feed of nodes created by friends of the current user?

Does the requisite relationship need adding to the view integration for this to be possible? Or, is there another way to do this?

CommentFileSizeAuthor
#18 filter_screen.gif11.47 KBraulreynoso
#7 friendlist_views.patch672 bytesdarrenmothersele
#7 friend_feed.view_.txt3.48 KBdarrenmothersele
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

UNFORTUNATELY Views can't do this. I'm gutted about this, because it would offer so many opportunities, namely micro-blogging. However, currently you could try activity_log which is in development stage. You could have some rules created (Activity Log is a glue module for Rules) that would return node titles from established relations.

I haven't tested this yet, but it is next on my todo list. In time activity_log will ship with some default rules, which will do exactly this.

I hope this helps a little bit, feel free to close if this answers your question ;)

Regards,

Marius

darrenmothersele’s picture

darrenmothersele CreditAttribution: darrenmothersele commented

I'm pretty sure Views 2 can go something like this. I just tried this, which seems to achieve what I'm trying to do, but I might be missing something?

I added a new join and filter declaration to the top of friendlist_views_view_data() to LEFT JOIN to the node table, and to add a filter on the requestee field based on current logged in user.

function friendlist_views_views_data() {

  $data = array(

    'friendlist_relations' => array(

      'table' => array(
        'group' => t('Relations'),

        'join' => array(
          'friendlist_statuses' => array(
            'left_field' => 'rid_origin',
            'field' => 'rid',
          ),
          'node' => array(
            'left_field' => 'uid',
            'field' => 'requestee_id',
          ),
        ),

        'base'  => array(
          'field' => 'rid',
          'title' => t('Relations between users'),
          'help'  => t("Relations between users in the system. They can be one-way or two ways"),
        ),
      ),


      'requester_id' => array(
        'title' => t('Requesting user'),
        'help' => t('The user who made the request'),
        'relationship' => array(
          'base' => 'users',
          'field' => 'uid',
          'handler' => 'views_handler_relationship',
          'label' => t('Requester'),
        ),
        'filter' => array(
          'handler' => 'views_handler_filter_user_current',
        ),
      ),

// ... rest of module ...

These are the two bits I added:

          'node' => array(
            'left_field' => 'uid',
            'field' => 'requestee_id',
          ),

        'filter' => array(
          'handler' => 'views_handler_filter_user_current',
        ),

Now I create a node table based view, and add the filter on "Requester: user is currently logged in user" and it produces this SQL... 

SELECT node.nid AS nid,
   node.title AS node_title,
   users.uid AS users_uid
 FROM node node 
 LEFT JOIN friendlist_relations friendlist_relations ON node.uid = friendlist_relations.requestee_id
 INNER JOIN users users ON node.uid = users.uid
 WHERE friendlist_relations.requester_id = ***CURRENT_USER***

Selecting all nodes where the author is on the receiving end of a friend request from the currently logged in user. I think this works for me as I'm only interested in one-way relations at the moment.

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

your solution does work. However, one bit really bugs me: is it enough to link to node via requestee, and only requestee?
What if a person want to link to it via requester? Or, better: is that a likely possibility? Or is it absolutely unnecessary?

You seem to know Views well. So, the real questions is: does this patch actually help people *in general*? Or is limited to this one specific case?

I am tempted to add it, because it seems to make sense. But, my "autistic" self working brain is not giving a definite answer... and this worries me. It could be for lack of information on my side, or it could be because the solution is partial. I can't really control how my brain comes up with solutions, it's a bit of a black box. So, I am a bit lost.

Bye,

Merc.

darrenmothersele’s picture

darrenmothersele CreditAttribution: darrenmothersele commented

You're right - this is a partial solution.

I'm still learning the ins-and-outs of Views 2. I know this works, but it doesn't feel like the right way to do it. I think in order to support joining on multiple fields the correct thing to do is use relationships, I've just not quite got my head around how this will work yet.

I'll see if I can come up with a more general way to link friend status to nodes using Views 2 relationships, as I think this may turn out to be a more general solution.

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

OK thanks.
Will close this issue as won't fix in a week or so if nothing happens... is that OK?

Merc.

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Hi darrenmUK,

Please let us now if you do figure out a way, since it would be immensely beneficial for many. I'm a little short on time this week, but will definitely help research a possibility in this direction.

I think the more scenarios we can solve with Views, the better! Also this concept is something that is not yet feasible in Drupal, believe it or not. So a half working solution to me doesn't count as 50%, but more like 80%...At 100% we will include it :)

Regards,

Marius

darrenmothersele’s picture

darrenmothersele CreditAttribution: darrenmothersele commented
FileSize
friend_feed.view_.txt3.48 KB
friendlist_views.patch672 bytes

@merc - I'm going to continue to look at this, so yes give me a week and you can close this issue off.

@marius - In the meantime here's what I have so far, and it works for creating a friend feed. Attached is the patch that adds the required join to the friendlist_views module so that the provided views integration shows up in views with Node as their base table.

This is working under the assumption that you want to join the Node and Relation table in such a way that the Requestee (i.e the people you are friends with) UID is linked with the Node UID. This allows you to then use the "Requesting user is current user" filter that I have added.

Attached is a txt file containing a view export which you can import into views 2 as an example. This creates a basic friend feed of nodes created by the current logged in user's friends.

darrenmothersele’s picture

darrenmothersele CreditAttribution: darrenmothersele commented

p.s. you have to clear the views cache after patching friendlist_views.views.inc - goto: /admin/build/views/tools and click "Clear Views' cache"

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Thanks darren...will try this out in the next few days!

Regards,

Marius

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Hi,

Alright, I'm back from a weeks vacation and tested its usefulness. Indeed it is very very useful. Agreed the implementation is not correct, so this brings up a bit of a dilemma.

your solution does work. However, one bit really bugs me: is it enough to link to node via requestee, and only requestee?
What if a person want to link to it via requester? Or, better: is that a likely possibility? Or is it absolutely unnecessary?

I think it is enough to link via requestee, since for two ways, it will work both ways. For one ways, it doesn't make sense to track people how are interested in you. You only want to track users you are interested in.

does this patch actually help people *in general*? Or is limited to this one specific case?

It is limited to this specific case. For example it only allows the filter to be exposed. Anything else won't work and could possible return an empty view all together.

I'll see if I can come up with a more general way to link friend status to nodes using Views 2 relationships, as I think this may turn out to be a more general solution.

That would be the best. The provided feature to allow content tracking is very important imho and must be included if at all possible. It would allow for a simple activity log without the need for a more fully featured activity module when simple tracking is required.

Also, I've set up this site to see how it could fair doing Micro-Blogging by creating a Twitter clone: http://groups.drupal.org/node/16023 Please check that out as well and let me know what you think.

Personally I would keep using this patch for my personal work, but I'm also hesitant to say it should be included _as is_ in to this module.

More development is very welcome!

Regards,

Marius

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

@darrenmUK: are you able to rework this patch to "generalise" it so that it can be included in the module?

Merc.

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

I am very torn about this patch.
Shall we just apply it? Especially after reading:

"I think it is enough to link via requestee, since for two ways, it will work both ways. For one ways, it doesn't make sense to track people how are interested in you. You only want to track users you are interested in."

...?

merc.

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Yes...I'm comfortable enough with it. If it is included...it can always be optimized by others. At least then they know about it, since it is included. Otherwise they might never find this patch in the issue queue. So, if you are comfortable with including this, I am as well.

Regards,

Marius

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

Marius, can you apply the patch (it should be straightforward) *and* make a note in the documentation about how to use it?

Thanks a TRIllion!

Merc.

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Yes...but I have to postpone the documentation 'till january. Should I already make the commit for the patch or wait until I've done the writeup?

Regards,

Marius

nadavoid’s picture

nadavoid CreditAttribution: nadavoid commented

Personally, I think that having a feature that is present (but not causing trouble anywhere) but not officially documented, is better than waiting for the feature until the documentation is ready. But documentation quickly following is pretty important too. :)

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

I'd commit it, making some short half-finished *provisional* 3 line documentation about it -- a sort of note to self, and to others if they read it.

Thanks!

Merc.

raulreynoso’s picture

raulreynoso CreditAttribution: raulreynoso commented
FileSize
filter_screen.gif11.47 KB

Hi Thanks for this information it was really useful to me. However I wanted a view of a users friends posts that was available to all. I could not find a view filter that allows you to view by the user id in the url, only by the currently logged in user. This means you can't really make the view public.

I started with darrenmUK's solution and added one more filter:

      'requester_id_any' => array(
        'real field' => 'requester_id',
        'title' => t('Requester user is comes from the argument specified'),
        'help' => t('Filter results so that only the argument user is the requester'),
        'filter' => array(
          'handler' => 'views_handler_filter_numeric',
        ),
      ),

Then I hacked the views_handler_filter_numeric.inc file to evaluate the argument that you supply when you create the filter. I replaced the code that is found on around line 235 with the following two lines:

    $trash = eval('$val = ' . $this->value['value'].';');
    $this->query->add_where($this->options['group'], "$field $this->operator %d", $val);

Finally, I selected the new filter, selected 'is equal to' and put 'arg(2)' (without quotes) in the filter form.
Only local images are allowed.
This gave me the desired results, but I was wondering if there is a better way to do this. Is there no way to filter a view by the user specified by the url? Using aguments doesn't work because this selects nodes who's author is the url id specified. I wanted nodes whos author was the friend of the url specified. Any ideas how better to accomplish this?

thanks.

mercmobily’s picture

mercmobily CreditAttribution: mercmobily commented

Hi,

@raulreynoso: Sorry, I am not sure :-/ This seems like a more advanced Views question, more than something that relates to this module...

Marius: YOu good with documenting this? Let's get this issue out of the way! :-D

Thanks,

Merc.

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Sorry raulreynoso, but this can not be accomplished for reasons you already stated yourself. Since your solution requires altering the view core files it goes beyond the current solution. The patch here discusses only the nodes of friends from the current logged in user. I realize it is miminal, at the same time most useful.

You could try to look into the activity_log module, however I'm not even sure if that could accomplish what you want.

Regards,

Marius

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented
Status: Active » Fixed

Now patched and committed.

Marius

raulreynoso’s picture

raulreynoso CreditAttribution: raulreynoso commented

Thanks for the feedback. I'll ask my question in the Views area. I thought I might be overlooking something, but the more I look at it the more it seems, there really needs to be another views filter handler to make this work properly.

raulreynoso’s picture

raulreynoso CreditAttribution: raulreynoso commented

i should clarify, the code I included above works, if anyone is interested in using it. But because it is a hack of views, its not the best solution.
--
Webology eBusiness Solutions
Cost-Effective Web Development
http://www.webologysolutions.com

mariusooms’s picture

mariusooms CreditAttribution: mariusooms commented

Also, if you do find a solution with another view type filter, please do open a new issue on this as it would be great to extend the use of node table views for friendlist. It should be no problem to commit solutions as long as it doesn't require altering other modules ;)

Regards,

Marius

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.