adding to buddylist must be approved by recipient

This module will most likely remain focused on role-based permissions. Moving to the correct project.

I'm very interested in doing this too. Want to make a myspace/friendster type site and want to have permissions for nodes be either
1. private (only owner can see)
2. buddylist (users in buddylist can see)
3. organic groups (users in same og can access)
4. public (all can see)

Any thoughts on this? I know 3 & 4 work already through OG, but I can't make private or buddylist perms.

did anything ever come of this? one HUGE permission rule that i'd like to see is the ability to control who adds whom to a buddy list - e.g. right now anybody can add anybody, but what about making it moderated by default, so that the recipient of a buddy request has to approve the 'add to list' request? this seems quite useful, and would allow for buddylist to morph into a full featured social networking tool for community sites on drupal...

this already works for OG, seems like it could be copied over to the buddylist module - though i'm not a coder (my developer is actually looking into this, so we'll keep you posted if we find the path..)

combined with the viewing permissions described earlier, this could become a killer app with potential for core distribution - since the community and grouping features are critical to users...imho

Yes, I agree. I'm actually doing some mods to buddylist and have been planning on adding this option and some other things. So it's on my agenda, just not super soon.

I've been evaluating Drupal for a few days and was extremely disappointed by the privacy/permissions limitations. Giving every user complete control over who sees their content is a make-or-break issue for me, unfortunately. My research on this site has given me the impression that this is something many people want, but this is the only place I've seen somebody actually say that they are working on it (thanks RobRoy!). I've also gotten the impression that this is a limitation that is rooted in the core of Drupal, which could not be fixed by an add-on module. I hope my impression is wrong of course!

I just want to share how I envision Drupal working for me, in a perfect world:
1. Users can create an arbitrary number of buddy lists, each with an arbitrary number of buddies.
2. Users can grant viewing rights on their content to any subset of their buddy lists, all registered members, everyone in the world, or nobody at all.
3. If a user doesn't have access to view somebody else's content, then they shouldn't even know it exists! If you aren't allowed to see an article then it should not show up in any lists or stats or blocks or anything for you. This is mostly because you may not want friends to click on a link to an article you wrote in a Recent Articles block and be told they aren't allowed to read it (which implies you have closer friends who are allowed to read it!).

Note that for something like a photo album, I'd prefer that the creator only needs to grant permissions on the album as a whole, not each picture. And for discussion forums, I think it would be better if permissions were granted at the topic-level by the topic creator, and those permissions would apply to every post in the topic regardless of who posted it. Comments that are attached to a node should inherit the permissions of the node.

I think in my version of things, there would be no reason to deny somebody's request to add you to their buddy list, as all it does is make more content available to you.

RobRoy, since you seem to have worked with the BuddyList module, do you have a strong idea of whether these things are possible? If so, do you have any intention of implementing them as I have described, and do you have any idea of when you might be ready to share your work?

As a last resort, can anyone suggest a CMS that can provide this functionality if Drupal can't?

Drupal can do just about everything if the right module is coded, so it can do all you want. It's going to take me around a month to get started on this so the time frame is not soon by any means. I'm also probably going to program this as an add-on to the og.module as it already has a lot of the features you may be looking for, just not with the same packaging. I'll let you know when I get started, but it will be a while.

hey robroy,

any progress on this module yet? i need these capabilities for sites that i'm converting to drupal from mambo for our nonprofit organization.

if you need any help testing and debugging, i would be really happy to help.

thanks,
blue

Is anyone working on this anymore?
Apparently there's now a myspace module which can be found at www.drupalnation.com

Take a look at http://drupal.org/node/28535.

Also the drupalnation.com link doesn't seem to be working at the moment.

http://www.drupalution.com/

Any updates on this? I would love to have this ability on the site I am building. Any help would be appreciated!

Has anyone done any work on these changes to buddylist?

We are about to unveil a social networking community for our nonprofit, and need these changes to the buddylist badly.

The most important change we need is that people have to invite someone to be their buddy before they can add them to their buddylist, and once that person agrees, they both show up on each other's buddylist.

I am not the best coder, but will attempt this if no one else has.

thanks,
blue

I just saw that Webchick is working on this functionality as part of the gojoingo modules.

http://drupal.org/node/44047

ok, reading this post I just need to replay.

I'm working on a project combining cms and sns. I have been rewriting the budylist module to a contact.module with approve/deny stuff in it and was looking to an integration with privatemsg.module and a rework of FOAF. So I'm actually rewriting a lot of the modules and wasn't sure how to communicate it with the community.

I will try to create a good module for 4.7 asap.

So, I'm just going to pitch in a bit here, with my own two cents. So, I like this module quite a bit, -- it has great functionality -- it seems very clean -- and it basically works.

Since many of the "Buddy" programs are invitation based, however, I do think it could stand to benefit from a "invitation" paradigm rather than a "add whoever you want to" paradigm.

I actually think that this could be done by only slightly tweaking the current module without that much difficulty or strain-- at least by somebody who knows their way around drupal. (I have also investigated "go join go"'s version of friendship requests-- which also seems functional, although the database structure seems a bit more specialized.)

Now, I am not sure how to quite do this in code, but here's my proposed "revision" of how to re-interpret the "buddy list database" information.

Pretend your buddylist databse looks like this:
database row: Userid = 2, buddy = 7
database row: Userid = 2, buddy = 9
database row: Userid = 2, buddy = 11

database row: Userid = 7, buddy = 2
database row: Userid = 7, buddy = 11
database row: Userid = 7, buddy = 9

database row: Userid = 9, buddy = 6

Instead of interpreting this as "userid 2 has userid 7, 9, 11 as a buddy" -- interpret this as "userid 2 has submitted a friendship invitation to 9, 11" and "userid 2 is friends with 7" (since the friendship request is mutual).

Also "userid 7 is friends with 2" and "userid 7 has submitted a friendship invitation to 9 and 11"

Finally, "userid 9 has submitted a friendship request to 6"

From there, it is simply tweaking the displays and the wording of the text:

You would need to create a new "friends" function so that it returns positive when the link is *reciprocal*.

From there, you'd just have to do some local translations, and switch the display / views stuff around, but that seems pretty much like it.

I don't have enough experience in drupal to do this myself, but I believe that from a cleanliness of database standpoint, this is the way it should be done, if anyone is thinking about tackling this problem.

Best of luck.

Maybe in 6 months, I'll try tackling this myself, if people think it's worthwhile.

Albert
www.ithou.org

Q: What's the MySQL query for *MUTUAL* buddies?

I've been struggling with this a bit -- trying to tackle the problem that I mentioned in the post above, but am having a hard time figuring out which SQL query selects:

*those people who have a "mutual buddy" relationship*, i.e., those people who are both "buddies" *and* "buddies of" another person.  

Any ideas here?

Thx.

Something like

SELECT * FROM {buddylist} b1 INNER JOIN {buddylist} b2 ON (b1.uid = b2.buddy AND b1.buddy = b2.uid)

will get you rows of mutual buddies.

Thanks RobRoy... I appreciate the lead! :-)

I'll dive back into the code and see what I come up with.

Albert

My take on the subject.

1) You will need the following changes to the admin page :
a) 'Require confirmation' checkbox
b) 'Mail friendship requests' checkbox
2) On the user edit page, you will need a mail friendship requests button too
3) you will need to add a 'confirmed' column to the buddlist database.
4) When a new friendship request is made, you will need to add the record to the
database, with the confirmed column being the opposit of the require confirmation setting (ie: !variable_get('buddylist_require_confirmation', TRUE) )
5) Then you will need to send an email, there are 2 forms for this mail, depending on whether the user has been confirmed or not. One of
these forms of the mail will have an 'confirm user' link, which will require login, and automatically add the user to your list.
6) Additional interface will be required to confirm users from within the interface.

Unfortunately, I think you do need the mail functionality to make the feature truly useful.

Thanks for your ideas, adrian! I'll keep working on this... tho' it's really new territory for me.

I'm actually thinking about doing this w/o adding any new database columns... and letting "confirmation" occur simply when the "invitation is mutual" ... for me, that seems the most "compact" and elegant way of doing this... but, we'll see if I can pull this off.

Best,
Albert

So, I think I'm actually close to getting a primitive hacked version of this working, much thanks to RobRoy's excellent SQL guidance, but I need a couple more MySQL queries --

So, for those gurus out there who know more about this than me... what is the SQL query that selects:

Those people who have *made* someone a buddy, but it's NOT a mutual buddy relationship, i.e., where it's a *one-way* "Buddies" relationship

.... and, also

Those people who have *been* made "buddies of" someone else, but it's NOT a mutual buddy relationship, i.e., where it's a *one-way* "Buddies OF" relationship

Thanks so much... and I'll post it here for people to test out as soon as I get these fixed... (It actually seems to work ok! -- though, there's still definitely room for improvement... but the database architeture and functionality seems basically sound, as far as I can tell..)

[BTW, right now, it's programmed, actually a substitute for buddylist.module, rather than an add-on -- but I wanted to get to proof-of-concept stage before any kind of integration.]

Albert
www.ithou.org

I think I've got it... So, to get all of the one-way buddies for uid = %d, from SQL, you can do a query like this:

SELECT * FROM `buddylist` b1 WHERE b1.uid = %d and b1.buddy != ALL (SELECT b2.uid from `buddylist` b2 where b2.buddy =2) 

whew! I'll let you know how it goes...

Albert
www.ithou.org

I think to find all one way buddies you'd want to do something like this. More SQL compatible

SELECT * FROM `buddylist` b1 LEFT JOIN `buddylist` b2 ON (b1.buddy = b2.uid AND b2.buddy = b1.uid) WHERE b2.buddy IS NULL

Cool, RobRoy, I'll give that one a shot, too!

The one that I wrote above also works, at least on my system, but yours is probably more general...

And the good news is... 'cause I've just been testing it out just a bit now at www.ithou.org.... I think this puppy actually works! ... albeit in a fairly primitive way. (Still no private msg integration)... Nevertheless, it's a solid database structure to build off of, and I think it's pretty lean and doesn't add much at all to the code -- and doesn't even require any additional columns or tables to the original buddylist schema. So, imho it's pretty compact. I'll try putting it up here once it gets closer to alpha. Hopefully by this weekend.... (fingers crossed!)

Thanks once again for all your help!

Albert
www.ithou.org

My first time trying to submit something like this... So, I don't know the proper protocol...

But... here it is... attached in its most basic, primitive form. It works on the same database as buddylist, but simply reinterprets the database structure in the manner described above. But the proof is in the pudding... Test it out. As far as I can tell, it actually works! (4.7 cvs)

But make sure to back things up first.

I'm sure there's probably some issues with it, but I plugged everything I could find. So, I hope you guyz like it. It is a buddylist-based system, but requires *acceptance* before becoming a friend.

Also, BTW, I didn't figure out my mods effect the *group* aspects of buddylist, though, so if I didn't do any debugging there. ymmv.

Best of luck!

Albert
www.ithou.org

Ooops, forgot to attach file... here it is...

So, more testing... and honestly, this really works! I ironed out a small notifications bug here with this update. (It *was* saying 'you've been invited to be a friend' when it should have said 'your friendship request has been accepted').

So, try it out! Tell me what you think!

You use the same database as buddylist.module, but just use this attached module in place of buddylist...

I need you to actually roll a patch for this. Here's why:

- I just made 2 commits on the existing version of buddylist, so now we've got a fork situation and you're going to have to apply those changes to your version just to keep abreast
- I can't easily compare the new/old versions so it is hard for me to evaluate
- it is the Drupal way of doing things.

This is not meant to discourage you because I want this functionality in buddylist. But it is the only way we can effectively work together (I mean all of us, all Drupal devels), so please do what you need to do to be on top of patching.

Here's a patch rolled off the latest drupal 4.7 download. As downloaded from :

http://ftp.osuosl.org/pub/drupal/files/projects/buddylist-4.7.0.tar.gz

from this page: http://drupal.org/node/3230/release

Patch is attached. Looking forward to your comments.

[This is how I rolled the patch. I downloaded the files from above. Then I renamed the downloaded buddylist.module into buddylist_old.module. I renamed my new/revised buddylist.module into buddylist_new.module. And then I ran the command:

diff -u buddylist_old.module buddylist_new.module >buddylist.patch

]

Hope this helps.

Eagerly looking forward to your comments and thoughts.

Please let me know if I am doing the patch thing correctly.

Just updating this patch... Here's the latest, now taken off of the cvs updates from 5/27/06...

Looking forward to comments and feedback.

Note: the SQL command:

$sql = 'SELECT b1.uid, u.name FROM {buddylist} b1 INNER JOIN {users} u ON b1.uid = u.uid WHERE b1.buddy = %d AND b1.buddy != ALL (SELECT b2.uid from `buddylist` b2 where b2.buddy = b1.uid) ORDER BY u.access DESC';

works as a way of finding all uni-directional buddies for MySQL 4.1 but not 4.0. Can anyone help me find a way to make this work for MySQL 4.0 also?

Doesn't my last comment do that?

Hey RobRoy! Glad to see you're 'round!

You're absolutely right. I should be clearer about what it is exactly that I need....

OK... so run with me on this... it's for a good cause :-)

What I'm really after is an SQL command that basically returns back a particular person's "snub list" [call that person %uid=diva] -- that is, I want an SQL that, when I feed it a particular user, [say %uid=diva] ... it tells me, in return, all the people who have designated that particular person[uid="diva"] as a buddy, but who he/she[the diva] has *NOT* in return designated as buddy.

So, the SQL that is listed below (which is what I need -- or at least the MySQL 4.0 equivalent) gives *all* users who have designated (uid=%diva) as their buddy, but who have *not* been designated by (uid=%diva) as a buddy.

SELECT b1.uid, u.name FROM buddylist b1 INNER JOIN users u ON b1.uid = u.uid WHERE b1.buddy = %d AND b1.buddy != ALL (SELECT b2.uid from `buddylist` b2 where b2.buddy = b1.uid) ORDER BY u.access DESC

[The "snub list" is eventually going to actually become the "Pending friendship invitations" list for uid=%diva.... in case you're wondering where this is headed.]

Anyhow, the code that you gave above lists *all* users who have *some* one-way buddy relationship happening in a given community..... [You could call it the "unrequited love" list *for the entire site*].

It's an "unreciprocated buddy" list *for the entire community*, rather than a "snub list" for *a particular person*.

Does that make sense?

Thanks for your help on this as always.

Regards,
Albert
www.ithou.org

BTW, this patch *does* work for MySQL 4.1 --- tho' it maybe time to branch, 'cause it doens't look like it's gettin' integrated anytime soon! :-)

@ajwwong, you need to submit the patch in a form that addresses one issue only, and without code comments that indicate every place you made a "MOD". So, starting from the latest clean buddylist, merge in your changes that have to do with the feature you're requesting, minus all the places where you changed "buddy" to "friend", and updating the comments to say what the code does, not how you changed it. Thanks.

Actually, RobRoy, I've looked it over, and your code works right [I've just added a little bit at the end like this].

SELECT * FROM {buddylist} b1 
	         LEFT JOIN {buddylist} b2 ON ( b1.buddy = b2.uid AND b2.buddy = b1.uid )
             WHERE (b2.buddy IS NULL AND b1.buddy = %d)

-- which is great... in fact, it's perfect.

The only small glitch for me is that in order to make it so that this code integrates seamlessly with the rest of what's happening in buddy list, at least at this stage in the code, I also need the "name" and the "email" of person to also be returned, in addition to the buddylist info.

To show you what I mean, I've tried something like this as a modification to your code, but it doesn't seem to work...

$sql = 'SELECT b1.buddy, u.name, u.mail FROM {users} u 
            INNER JOIN {buddylist} b1 LEFT JOIN {buddylist} b2 ON (b1.buddy = u.uid  AND b1.buddy = b2.uid AND b2.buddy = b1.uid) 
            WHERE b1.uid = %d AND b2.buddy IS NULL' 

Any help would be appreciated.

Best,
Albert

Hey Robert,

Thanks for taking the time to respond! Wasn't sure you were out there or not... :-)

Well... the more I think about it, I think you're absolutely right. This so-called "patch" of mine doesn't really just tackle one issue.. it tackles a bunch at the same time... some of that is trivial stuff.... like changing vocabularies and words, but some of it is really core -- 'cause when you brush away all the trivial stuff like wording changes, etc., it's not so much a "patch" as it is a fully recasting of the buddylist database interpretation. It's really an architectural "remake" not a patch.

Good luck!

Albert

I was just wondering if someone could point out what I'm doing wrong. I installed the new buddylist, I was using the original one before. I can invite users from an admin account, but from an authenticated user's account i get 'Access denied You are not authorized to access this page.'
Is there something I'm not doing right

Hey, specialt --

Glad you're giving the new module a whirl.

Not sure if this is what's going on, but it sounds like your access controls aren't re-set yet.... possibly?

So, go to the menu item...

administer > access control

Look under the buddylist.module access controls and make sure that the module has the settings appropriately set to allow both

"maintain buddy list and
view buddy lists"

for authenticated users.

Then, you should be able to invite buddies / accept friendship invitations for people other than admin. :-)

Anyhow, at first glance, this sounds like what is going on. If this doesn't work for you, let me know and I'll take a closer look....

Another possibility --

Also, have you deleted the old buddylist.module yet -- or taken it out of the modules directory? Sometimes having the old module around can mess up settings, I think.

Best,
Albert

Great job ajwwong,

but i have 2 problems left:

1) using the new buddylist-module:
If somebody invits another, there is a link to accept the friendship, which you can only accept not really cancel.
What i need is, that when you press cancel that the friendship - request would be canceled and i need help doing this, because i am very new to drupal.

2) developing buddylist-module:
I want to create an textfield in which you can write a reason for inviting someone to your friendship.
For this i need to save the $reason into the database (table buddylist: uid, buddy, timestamp, received, reason(text)).
The problem with this is, that there are so many functions which i have to give the variable $reason as parameter, and there is one function called "buddylist_deletebuddy_confirm_submit" and i cannot find where this function is called.

If someone please could help me.

I am so blind.

Problem 2) is no more -> i am working on problem 1).

great! thanks for working on this branch of the module with me! :-) And glad you like it....

I'm pretty busy thru this weekend, but I'll try to give it a shot soon.... btw, how did you solve #2?

thanks!

Hi,
I am unable to create a patch so i post the new buddylist.module ("buddylist17072006.rar").

Whats new:
textfield for reason added
when accepting you can now choose "Nachricht schicken" (= "send Message", I am from Austria) which automatically links to the private message module to send a message to the user which is asking for friendship-request

requires:
you have to do a database update:

CREATE TABLE {buddylist} (
uid int(10) unsigned NOT NULL default '0',
buddy int(10) unsigned NOT NULL default '0',
timestamp int(11) NOT NULL default '0',
received tinyint(1) NOT NULL default '0',

/*NEW:*/
reason text,

PRIMARY KEY (uid,buddy)
) /*!40100 DEFAULT CHARACTER SET utf8 */;
MYSQL_UPDATE
);

I am not shure if this create statement works because, i have manually added this column

Has any progress been made on this?

hi blue,

thanks for your interest in this feature.

i haven't checked out the latest version posted by oesti above, but there's a couple of people who've reported working versions of this patch/modification to buddylist.

additionally, there apparently has been private message integration work done, which i'm excited to check out, once i get the chance.

feel free to try it out and let us know what you think.

best,
albert
www.ithou.org

Hey Albert (and others working on this),

I've installed and tried the version that oesti posted, and it seems to work well, but there are a couple of issues:

1. It does not offer a way to decline a friend invite. You can accept, but not decline, which is an essential missing function.
2. Having a notice that you have been invited to be someone's friend appear in the page when you login, and then having to go to that person's profile to accept the invitation is very counter-intuitive. I would definitely prefer this to be tied into the private message module.

Do you know who is working on the private message integration? I would love to test this out.

peace,
blue

These are popular feature requests. It makes sense to:

1. have a setting that extends the current workflow so that the receiving user has to approve the 'add to buddylist' request
2. add the ability to include a private message when adding a buddy
3. #2 can be done via the privatemsg module

#1 is its own issue. #2 and #3 are a separate issue. I'm closing this issue and opening two new fresh issues.

As it is, many people have worked on this but nobody has offered a patch that can be used. If you want to work on these issues and get them included in the buddylist module on Drupal.org, I need patches that only focus on one of the issues at a time (don't change other aspects along the way).

I'm adding maintainers to this module and am finding more time for its upkeep in general. The buddylist module is crucial to Drupal's social networking features - let's get organized about this feature and get it in!

just a link to track

Here is Oesti's (see comment #43) module patched so that

1) the reject works.
2) there is a module_exists wrapper on the privatemsg call
(Additionally there was some drupal form cleanup performed on Oesti's form controls only)

I know that this is not in line with the module developers requests for this module, but I inherited the code I got and so cannot provide a file by file patch, because I am unsure where oesti started his code from.

Thanks for your work on this. I'm thrilled that people are using and improving upon this mod to buddylist. I'll try and check it out when I get the chance.

Hi there,

I'm just testing out this new code for use on my website. When I tried to add a user to a group I got this error message:

warning: Invalid argument supplied for foreach() in /home/huitkcom/public_html/modules/buddylist/buddylist.module on line 734.
warning: Invalid argument supplied for foreach() in /home/huitkcom/public_html/modules/buddylist/buddylist.module on line 734.
buddy groups saved.

But it added the user ok. Any thoughts on this?

Thanks,

Neil

See comment #25 above. These mods have not been debugged for group aspects of buddylist... ymmv

Guidelines:

1) Don't change the title and version of the issue, please.
2) Submit patches. I *do not have time* to look at your entire uploaded buddylist module and make a patch for you. Learn to create patches or find someone who can help.
3) Address one thing at a time. I will not commit a patch that does 2-5 things in it.

Sorry to be a hardass, people, but I'm maintaining this thing in my freetime and have to be able to work efficiently on it or it won't work at all.

any recent update on this?

have a look at this more recent issue:
http://drupal.org/node/80116