I am not sure if this belongs in the buddylist feature request or this one.

Has anyone put the buddylist tables into the views module?

the concept being - build a block, or page, or whatever view that displays certain node types (or anything), filtered by current users buddies, or by buddies groups (exposed filter)

jason

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Project: Views (for Drupal 7) » Buddylist
Version: 4.7.x-1.x-dev » master
fago’s picture

this sounds like being really useful. would be cool if this works with userlists created with the help of the usernode module

robertDouglass’s picture

fago - care to take the lead on this?

fago’s picture

Sorry, I would have a look at this, however I'm currently too busy for this.

jbhan’s picture

I am placing a $200 bounty on this feature request.

contact me for details!

jason

robertDouglass’s picture

jbhan, that's really great! For whomever is interested in developing this, and collecting the bounty, I will gladly look over your code/patches, lend advice or guidance, and discuss options and strategies with you, if wanted. Thanks jbhan for offering some incentive for getting this done.

In case it is your first time writing views, you'll want to read the documentation, and study views/modules/views_user.inc for guidance. To get to buddies you'll have to do a buddylist_views_default_views() where you define the buddylist table and specify the users table as the left component of the join. You may also have to re-define the users table with an alias and specify the buddylist table as the left part of the join, so you'd be joining users->buddylist->users. That way you can list all the user information about a person's buddies.

Another interesting thing to do would be to get the group(s) that a buddy is in, and let the view be sorted or filtered by buddy-group.

Finally, you'd want to be able to get to the content of a users buddies. You'd do this by defining a filter on the buddylist table.

Cool stuff! Make sure to pop on in to the http://groups.drupal.org/views-developers group for more discussion.

jbhan’s picture

Thank you all for your intrest in the bounty! There have been several responses and all from qualified drupaler's!

The bounty will go to the person who writes the patch that gets committed to the module.

jason

robertDouglass’s picture

Again, let me reitereate that anyone interested in the bounty can feel free to contact me, ask questions, discuss implementation, etc.

drawk’s picture

Thanks for the post above, Robert. Very helpful information.

I'm currently playing around with this.

drawk’s picture

FileSize
378 bytes

A patch for Views integration. The patch basically just adds an include line, so will need the buddylist_views.inc file that I'll attach to a post below this one.

drawk’s picture

FileSize
3.7 KB

Include file

robertDouglass’s picture

This looks close to being ready to go, great work! When I add the default buddylist view, I get errors:

    * An illegal choice has been detected. Please contact the site administrator.
    * An illegal choice has been detected. Please contact the site administrator.
    * An illegal choice has been detected. Please contact the site administrator.

Getting this cleaned up is the only barrier to me committing the patch.

fago’s picture

FileSize
1.57 KB

hi
I had a quick look at it too.

<code>
        'name' => t('Buddylist: User Name'),
        'help' => t('This will display the author of the node.'),


I think this is supposed to display the name of the buddy? But, if I can list only nodes of my buddies what is different to the node author field ?
The same with the user picture, what is different to the user picture field of the node author?

<code>
      'currentuid' => array(
        'field' => 'uid',
        'name' => t('Buddylist: Author Is A Buddy Of Current User'),
        'operator' => 'views_handler_operator_eqneq',
        'list' => 'views_handler_filter_usercurrent',
        'help' => t('This allows you to filter by buddies of the current user.'),
        'cacheable' => 'no',
      ),


I have not tried it, but as long as you use the ***CURRENT_USER***' value it should be cacheable - and 'views_handler_filter_usercurrent does.

Perhaps an buddylist argument would be nice too. -> What about using the uid as argument ?

Further, a view which lists the friends of an user would be great..
This can be achieved by using the usernode module. Further I added this to the buddylist views integration:

<code>
if (module_exist('usernode')) {
  $tables['usernode_buddylist'] = array(
    "name" => "buddylist",
    "join" => array(
      "left" => array(
        "table" => "usernode",
        "field" => "uid",
      ),
      "right" => array(
        "field" => "buddy",
      ),
    ),
    'filters' => array(
      'uid' => array(
        'name' => t('Buddylist: Usernode Is A Buddy Of Username'),
        'operator' => 'views_handler_operator_or',
        'list' => 'views_handler_filter_username',
        'value-type' => 'array',
        'help' => t('This allows you to filter by buddies of a particular user.'),
      ),
      'currentuid' => array(
        'field' => 'uid',
        'name' => t('Buddylist: Usernode Is A Buddy Of Current User'),
        'operator' => 'views_handler_operator_eqneq',
        'list' => 'views_handler_filter_usercurrent',
        'help' => t('This allows you to filter by buddies of the current user.'),
      ),
    ),
  );
}


This is different than filter by the node author, it filters by usernode owner. Filtering by node author works too, because as default usernodes are authored by its owner - however admins or other modules might change the node authorship and things would break!

I've attached an exported view, which lists the buddies of the current users. Again, an uid argument filter for this would be nice and not hard to do, too.

This view can be easily extended with stuff like user pictures, latest login time and so on. If one uses the nodeprofile modules it could be extended to list profile data by using the views_fusion module.

fago’s picture

Ah I forgot to note, that I had no problems with the installation. However, perhaps a update that invalidates the views cache would be a good idea.

drawk’s picture

Interesting about the install problem. I've tried it on a couple of test sites, and Jason and Fago didn't seem to have install issues. I'll take a peek.

Fago -- the Buddylist: Username and Buddylist: Authorname I have in there in order to be able to have quick access within of a view of the user who's buddies are being referenced in the view.

That is, I might want a view that lists say "User | Buddy of user | Title of a node published by buddy of user"

So you can access info either about the user who's buddylist you're working with, or users who are buddies of that user.

Hmm. Hope that isn't too terribly confusing.

drawk’s picture

Hmm, I can't see anything in buddylist_views_default_views() that should be causing the errors Robert gets when adding the default view.

Very strange.

fago’s picture

yeah, but if you use the filter: list nodes authored by a friend of user X, then the author is obvisouly your buddy, so the node author name field is exactly the same as your buddyfield name. so you could do this view by using the node author field.

In case of using the ther buddylist usernode filter, the usernode: name field is exactly the same.

drawk’s picture

yeah, but if you use the filter: list nodes authored by a friend of user X, then the author is obvisouly your buddy, so the node author name field is exactly the same as your buddyfield name. so you could do this view by using the node author field.

But the author field name isn't the same as the "username". The author is your buddy. But the Buddylist: Username isn't the name of the buddy, it is the name of the person who that buddy "belongs" to.

It could probably be named something more clear. But say you do a view of buddies who are in "Dave"'s buddylist. Buddylist: Username would be "Dave", not the name of his buddy/buddies. You can access the names of the buddies who belong to Dave that are being listed, of course, in other ways - that is really the point of the integration - but it seemed handy to also be able to access the name of the person who's buddy list these things are being pulled from.

drawk’s picture

Sorry about that. Forgot to close my blockquote above.

I was chatting with merlinofchaos, and he was kind enough to review the code for the default view, but did not see any reason why it should be throwing those errors. From what I can tell from searching, the errors are related to forms API related security checks. Why they should be triggered in Robert's case - in this context - however, is still a mystery.

Merlin suggested that they can occur particularly after vocabulary terms are deleted. Not sure if that is applicable in this case.

It is a difficult thing to debug, because the code looks ok and it has so far affected only 1 of 4 people who have tested the patch. Would be nice if anyone else out there would be willing to apply it and see how they make out.

fago’s picture

ah, right.. so perhaps the field could be renamed so that it's more clear which username is displayed?

@the choice errors.
I agree that it can't be this views integration, which caused this errors and if, it would be a views bug.. ;) So it shouldn't stop this..

jbhan’s picture

I know i have discussed this wirh drawk, but i though i would throw it to the thread.

The idea of using the buddylist group for a view. the problem with this is that multiple users may have a group named 'friends' - thus a view listing the buddies in group 'friends' would return all of the users who were in ANY group labeled 'friends'

the 2 possible fixes described were either prefixing each group name with the username, such that the group friends, then becomes 'drawkfriends' . the other involves silently tagging group name with a separate field.

i am not sure which way would be better, as both solutions would require a bit of change to the module itself, and not simply an include, and i suppose a question i have is how exactly would this display in the views module?
would there be x number of filters produced where 'x' is the number of users that have groups? would the list be huge and unmanageable?

i suppose the utility would be in a view displaying the nodes (or whatever) of current users (or other users)buddies in the group friend(or whatever)

lol, did that make any sense??

jason

drawk’s picture

I much prefer going with the prefix.

ie. "drawk - friends"

Then behind the scenes, translating this to the actual database group id of "drawk"'s friends group. The reason being that if we do it silently/hidden, then when you are constructing your view and choose the filter "Buddylist: Groups", you may still be presented with a bunch of indistinguishable group names (like 5 instances of "friends") without being able to tell exactly what belongs to who.

Open to suggestions, though. The group filter would be a very cool add on, and something I plan to implement.

fago’s picture

hm I can't see the actual problem?

looking at the buddylist database scheme you see groups are identified with (uid,label_id). I suppose the uid is the group owner.
So there is no need to do such prefix hacks.

fago’s picture

ah, the problem is the views ui select, yeah?
Hm, you could try to create a select with optgroups, or just create the prefixes.

drawk’s picture

Yep, the problem is with the UI select. There's no actual problem from the coding side, it's just that it would be confusing for the person who is using Views with buddylist.

I hadn't considered using opt groups. That might be a cleaner approach.

drawk’s picture

Congrats on joining the buddylist project as a maintainer, fago! That's excellent.

So there was some discussion that Buddylist: username might be a little confusing. Any suggestions (anyone) on what might be a more appropriate title for that field?

fago’s picture

thanks.
What about keeping the "confusing" name and describing it closer in the field description?

drawk’s picture

FileSize
3.7 KB

How's this?

drawk’s picture

FileSize
3.75 KB

Argh. Silly Windows box.

I meant this file.

robertDouglass’s picture

Status: Active » Fixed

committed to 4.7. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)
willzyba’s picture

Title: expose buddylist tables to views » "An illegal choice has been detected. Please contact the site administrator."

Hi All,
I'm new to Drupal but not to web development.

Installing things out the box, I'm getting the same error Roger reported ages ago when the module was being setup. Any clues as to what I'm doing wrong. The only two modules I've installed are the Buddylist and views !

Will.

willzyba’s picture

I mean Robert, not Roger. Sorry Roger..

fago’s picture

Title: "An illegal choice has been detected. Please contact the site administrator." » expose buddylist tables to views
Status: Closed (fixed) » Fixed

please don't change the title. I also ran over the "An illega choice has been.." problem now. It seems that an invalid input filter default value for the included default view has caused it. I've committed an fix which has solved it for me.

Anonymous’s picture

Status: Fixed » Closed (fixed)