Right now when Buddy API removes a buddy this only happens one way (one out of two rows from buddylist table).

However it is reasonable to argue that in case of confirmed friendships (two-way buddies) if either buddy breaks off a relationship it should invalidate the relationship both ways. This is how sites like Facebook work creating user expectations.

Question: What is the best way to address this in Buddy API (in Buddylist 2) to provide enough flexibility ?

CommentFileSizeAuthor
#4 buddylist_ui.module.patch775 bytesdkruglyak

Comments

nodestroy’s picture

nodestroy commented

Hi,

thx for you feedback!

the current state is:
************
function buddy_api_remove($userA, $userB, $buddyinfo = array()) {
[...]
// remove the connection between userA and userB (userA -> userB)
db_query('DELETE FROM {buddylist} WHERE uid = %d AND buddy = %d', $userA->uid, $userB->uid);

// if it is a two way connection, remove the userB -> userA connection too
if (!$buddyinfo['oneway']) {
db_query('DELETE FROM {buddylist} WHERE uid = %d AND buddy = %d', $userB->uid, $userA->uid);
}
}
************

Normaly there should be no inconsistency.
As I sayed...normaly, there are some scenarios where it can happen:

Time X:
- Buddy API is in one-way mode
- module Y changes one-way into two-way mode (module_invoke...)
- userA adds userB to his buddylist

Then, there are two entries in buddylist table.
(userA - userB + userB - userA)

Time X+1:
- Buddy API is in one-way mode
- module Y changes one-way into two-way mode
- module Z changes it back to one-way
- userA deletes connection to userB

[or moduleY is beeing disabled]

-> inconsistency (userB - userA stays in buddylist table)

i think, site-designers have to handle this problem by there own. (have to choose between one and two way)

any other ideas?

regards,
dominik

dkruglyak’s picture

dkruglyak commented
Title: Buddylist API: One vs. Two Way Buddy Removal ??? » Buddylist 2 needs to handle one-way mode properly
Category: feature » bug
Status: Active » Needs review

I did more testing in one-way mode (helped by latest UI fixes) and looks like there was a simple bug in buddylist_ui. Unlike buddylist_ui_addbuddy_submit, the deletion function did not check for oneway condition. The fixed logic is here:

/**
 * @param $form_id
 * @param $form_values
 */
function buddylist_ui_deletebuddy_submit($form_id, $form_values) {
  $buddyinfo = array();
  $buddyinfo['oneway'] = variable_get('buddylist_ui_oneway', 0);
  buddy_api_remove($form_values['requester_account'], $form_values['requestee_account'], $buddyinfo);
};

I did not make another patch to avoid confusion with the one just filed, but the above replacement should be trivial.

Still, this does not fix all problems with one-way mode

Right now there seem to be some wrong assumptions hardcoded into Buddylist API.

One-way buddy add does not generate a request or notification. While two-way request is mandatory for obvious reasons, one-way add should at least have an option to generate a request for reciprocal addition - called through the API. At the very least, there is inconsistency in Buddylist UI that still asks for "message" in one-way add request, but never sends it.

This should probably require another parameter in $buddyinfo, plus some logic to theme one-way request messaging.

nodestroy’s picture

nodestroy commented

Hi,

i added the two lines, its allready into cvs!

@option to generate a "two way connection"
do you really think, that this is valueable für buddy_api/ui? i think, if the whole site is in one-way mode, and userA adds userB to his buddylist, userB is also able to add userA. my plan is, to implement named relations (soon), then you can choose, which connection type should be used. e.g: buddy (twoway), college (twoway), "bookmark" (oneway), "not so well known person" (just to keep track connection - oneway)

then the option at oneway connection type would be redundat.

@message
i thougt about i message field to save the "reason" for the buddyadd. (of course, atm the message field only exists at buddylist_pending_requests). but it would also make sense for one way buddy requests. (don´t know if you now xing.com, there is an field "reason...") what do you think about this?

regards,
dominik

dkruglyak’s picture

dkruglyak commented
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new buddylist_ui.module.patch775 bytes

One more fix is needed - delete submit function needs to actually use the $buddyinfo!

Now as to one-way friend addition - I believe request for reciprocal friending should be optional / configurable, not mandatory. In some cases, one-way add is nothing more than bookmarking. In other cases this could be the first step to initiating a two-way relationship. I do not think either behavior should be hardcoded - there should be an opportunity to configure it either way.

This however brings up a bigger issue.

Right now Buddy API supports only one kind of request - to create a friend relation. However there should be all kinds of arbitrary requests possible between friends (maybe even non-friends) - to be implemented by contrib modules. If you are on Facebook and have used their apps, you'll know what I mean. In any case I can point you to a few select pages in their API documentation -
http://wiki.developers.facebook.com/index.php/Request
http://wiki.developers.facebook.com/index.php/Fb:request-form
http://wiki.developers.facebook.com/index.php/Fb:req-choice
http://wiki.developers.facebook.com/index.php/Fb:request-form-submit

Now as for "reason" there is a huge difference between recorded relationship type and a request message that gets passed to target user to incite action. Right now the request form content is only used for messaging. Again, look how Facebook handles "friendship types".

So this comes down to how to generalize the notion of a "request" and deploy it for all kinds of communication between buddies.

I suggest to close this issue as far as basic one-way bugfix is concerned and move the discussion of requests / activities / notifications to the issue I created on the integration with Activity module (http://drupal.org/node/203335)

IMHO, Facebook is by far the best in thinking through the concepts of friend relationships and activities. Please contact me via drupal.org form, so I get your email to connect on Facebook and show what I am talking about.

nodestroy’s picture

nodestroy commented
Status: Reviewed & tested by the community » Fixed

fixed

further discussions about API changes at: http://drupal.org/node/203335

dkruglyak’s picture

dkruglyak commented
Status: Fixed » Closed (fixed)

All done