buddylist 4.7 back port from 5

I'd do it the same way slashdot does. You get notified that someone added you to his friends list ('buddy' doesn't sound too serious). You can click a small icon to add him. If you do, you're both on each other friends list (mutual friendship). If you don't, it's not a mutual friendship; you show up as a friend in his list, and he shows up as a `fan` in your list. So you can have a list of friends, mutual friends and fans. Each could be a role so that you can define access controls.

There is a patch for this functionality here:
http://drupal.org/node/11892#comment-139473

this looks like an entire module rewrite. there have been severl new module commits recently. is there a patch that can be added to the up to dat version of buddylist?

j

... there needs to be a new menu item and page that lists all pending ...

I've done something similar. However, rather than use a menu item, I created a block for it. If there's no pending actions returning array() is just a blank block and doesn't get displayed. Otherwise the magic block appears. Just where the site admin placed it. You have to remember to tell the site admin to place the block somewhere on the page in the README, otherwise it never gets displayed ;)

Oh, and I'm subscribing to this issue too as I'd like to see how it progresses.

Regards,
--AjK

I'm currently working on this and am close to a first patch. I'm hoping once we get a basic patch committed, we can discuss finer details afterward. Currently we (advomatic.com) have a client anxious to get this going soon and adding just the basic approval functionality has been quite a task. With buddylist there are a lot of fine details to pay attention to just to implement a basic request/approval mechanism. I'm thinking blocks and other tuning can be added in subsequent patches...

Will have something soon so we can backport to 4.7 soon ;)

Great!
I had planned to work on this too. Blocks could be done by a views integration very well I think.
Do you include a place, where users can manage their pending and/or denied requests?

I'm looking forward on the patch, too :)

Yes, the patch (which should be up in the next 2-4 hours) includes tabbed links next to the buddylist tab for pending requests (1 for requests that the user has made to be added to other people's buddylist and 1 for requests that the user him/herself has sent to be added to the buddylist of others).

-Ankur

So, here's the patch and some details.

I made the following assumption: With buddylist approvals, the buddy relation is symmetric (i.e., if you approve someone's request to become your buddy, you are their buddy as well).

Now for some details about what's implemented in this patch:

(1) A setting for requiring approval. When the request is made, an entry is created in a new table, {buddylist_pending_requests}, and a drupal_set_message() is generated when the requestee logs in.

(2) A setting for sending an email to the requestee to inform them that someone wants to be their buddy.

(3) Two tabs on the same screen that holds the tab for viewing one's buddylist: one called 'requests' to list other users that have requested to be _this_ user's buddy (that are still pending) and one called 'requested' that lists the users that _this_ user has requested to be the buddy of (that are still pending).

(4) A setting for mailing the requester when the requestee has approved a buddy list request.

Please hammer away with tests, I've done a good amount of testing myself.

Things that may be still desired:

(1) Perhaps a setting in the case that a requestee is denied approval.

(2) Perhaps a mechanism that does a drupal_set_message() to let a requestee know s/he's been approved the next time s/he logs in.

In anycase, I'm anxious to start working on a backport as soon as this is tested, perhaps revised, and committed.

-Ankur

this sounds great! i am still using the good old 4.7.2 so i get to anxiously await your backport. I have a few questions about the patch.

1 - are the settings for the emails user controlled settings, or administrator controlled settings? (user controlled would be ideal)

2 - any consideration to allowing a short message to be attached to the request? usernames may not always be redily identifiable to requestees.

3 - any thought of ability to limit the number of invites from one person to a specific person...or for one user to block another users ability to invite to his buddylist? i'm thinking of repeat spamming of invite requests. after denials. (make sense?)

this patch sounds great! thanks for your work and that of your client!

j

Hey jbhan,

(1) The emailing settings are admin controlled. This I did because I wanted the code to be as analogous as possible to the existing code in the module. If there's a move for it, perhaps someone can submit a patch that makes these things user-controlled (or configurable between admin-controlled and user controlled).

(2) The message that informs the requestee (the next time the requestee) logs in links the user name to the user profile. If the tracker module is on or the profile module is on then, depending on how the admin has configured the site, the requestee should have enough context about the user. Also, w/ private message installed, it may be possible for the requester to send a private message.

(3) Blocking a spammer making repeated requests might very well be appropriately placed in a contrib module. You could create a table that counts requests and have a configurable limit of the number of requests that have been made and the number of requested that have been denied (vs cancelled). It should also be relatively easy to implement using the forms API, using the #submit value in hook_form_alter().

This is good news. I'll try it out on a test 5.0 site.

Thanks,

Jim

in regards to Roberts comments about the email link in #17. i think thats a neat idea. another possibility would be to have 2 links. one for you approval queue (robert provided) and a second to the username of the inviting user.

or just the ability to customize the email. (which may be possible already, but i dont' know since i just have to sit here and bite my fingernails waiting for 4.7 ! :)

j

I second the request for backport to 4.7. We're going to be operating with 4.7 for months to come.

Thanks for your work, ankur!

peace,
blue

ditto on the backport to 4.7. We're going to be operating with 4.7 for months to come.

Thanks for your work, ankur!

jim

Nice work! I haven't had a chance to test it ankur, but it looks like you're on exactly the right track / path... i.e., the real key is to let the buddylist relationship be *symmetric*. I put together a proof-of-concept module for this about a year ago... link to thread is posted below.... but it looks like we were totally in sync on our thinking!

Here's just a little comment in case you're interested in making this as compact as possible from an information-management point of view.

Comment: So... you actually may not need to set up a new database table to manage "pending buddylist requests"... with a requester_uid and requestee_uid, if you follow the database reinterpretation framework described here:

http://drupal.org/node/11892#comment-89499

Anyhow, this method described above saves you from having to create a new table.... so, it's good from that point of view.... if that's of interest.

You probably have already seen that thread, listed above, but there's some good code that sprang up out of this intrepretation that might be of assistance to you (even if it became a renegade branch! sorry robert! :-) ) ... and so, even if you don't want to drop your extra table, you might want to follow this thread above anyways, 'cause it might save you some time later on, especially, for example, with the privatemsg integration.

thanks for bringing this forward... and glad to see that the basic database buddylist symmetry structure is *finally* being done right! :-)

regards,
Albert
www.ithou.org

This patch addresses #16, and #17. As for #15, Robert, you're right about my doing a variable_get() twice. I overlooked that the define() creates a global string variable that is the result of the variable_get() which is what we want for the default value.

For #16, I just put in a link to the buddylist.

-Ankur

Correction to the previous comment: For #17, I just put in a link to the buddylist.

Here's another revision of the patch submitted in #24.

There was a bug in that patch: The macro for the pending-requests-link was pointing to the requester's pending requests instead of the recipient's pending lists.

-Ankur

Hi,

I'm having problems updating buddylist with above module patches. Can someone please post the updated modules?

Thanks,

Jim

I've just tested all this and committed your patch from #26. thanks for this great work :)

a similar problem I ran over:
If I requests to add user A, user A can request do add me. So both have requested to add the other one but there is no connection.
I would suggest to display the possibililty do accept the pending request instead of showing the "add user B" link, if user B has already requested to add you.

Further there is a lonely tab "buddies" above the other tabs. Wouldn't it be better to hide it if approval mode is on?

I'm trying to back port 5.0 buddy request stuff to 4.7.4. I've added the code and tested out some things but I'm hitting snags on others. Any php volunteers to help finish it off?

Jim

Hi Robert,

The requests are getting generated but checking them causes errors. Attached is the back ported module.

Thanks for your help.

Jim

Has anyone had a chance to look at the 4.7 backport that jwilde provided? Any progress on this?

I actually was going to look into this right now. I had a half-way backported untested version, but never got a chance to complete it. I'll be updating this thread in the next few hours.

Here's a patch that backports the two most recent patches to 5.0.

Here's how I did it: I took a diff of HEAD's most recent revision against the revision two patches ago (since stuff was added in two patches). I then applied it by hand to the most recent 4.7 revision (i.e., edited the .module file in an editor while looking at the diff output rather than using patch which would've failed on n out of n hunks).

Then I made the least amount of changes possible so that the result would work in 4.7 again. This mainly meant backporting the t() function calls, changing the way drupal_get_form() was being called, and changing the call to drupal_mail() back to 4.7's user_mail().

In anycase, I tested/debugged this patch out on a fresh 4.7 install and it seems to work fine. Please feel free to test away.

-Ankur

Patch seems to work fine.

Thanks ankur!

thanks ankur, committed to 4.7

Nice work ...... can any one tell me how to put these patch files to the buddylist.module coz I'm not much failure with editing drupal module files. I appreciate if someone can post the final buddylist.module with all the above patches included. Or can someone guide me how to put these patches to buddylist.module. Thanks

Hey chamara,

These patches have already been committed to the module in the repository.

All you have to do is download the module at http://drupal.org/project/buddylist and you will get it will all of this as a part of it.

peace,
blue

Hey thats great. Thanks for the reply :)

I have already replaced the new buddylist module to get these new functionality. But I'm getting an error message saying

user warning: Table 'drupal.buddylist_pending_requests' doesn't exist query: SELECT bpr.requestee_uid, u.name FROM buddylist_pending_requests bpr INNER JOIN users u ON bpr.requestee_uid = u.uid WHERE requester_uid = 1 in C:\xampp\htdocs\drupal\includes\database.mysql.inc on line 121.

Also I cant see any uer approval things happening. Am I missing anything?

yes. run update.php on module updates.

ok thanks a lot. now I got the Idea...everything works fine now. thanks for your help.