Modify Add Friend button logic based on who initiated request

[terraling]

I propose minor changes to bp-friends-classes.php and bp-friends-template.php which will leave them functionally unchanged for most users but will allow theme developers to adjust the behaviour of the Add Friend buttons via the bp_get_add_friend_button filter to resolve this use case problem:

John sends a friend request to Lucy.

Lucy receives an email notification which invites her to check out John’s profile.

When she does she sees his penchant for S&M and she also sees a ‘Cancel Friendship Request’ button which she promptly hits.

She gets an error message ‘Friendship request cannot be cancelled’, which she doesn't understand but which is because she can’t cancel it because she didn’t initiate it.

Currently, check_is_friend (in bp-friends-classes.php) returns 'is_friend', 'not_friends' or 'pending'. 'Pending' doesn't distinguish between whether the user initiated a request or received it.

I propose to alter the test so that 'pending' is returned if the user initiated the request, and 'respond' if they are the recipient of a request which is awaiting their response.

To avoid breaking anything, in bp-friends-template.php the function bp_get_add_friend_button adds a test for 'respond' but builds $button exactly the same as for 'pending', except for $button[id]='respond'.

Then if a theme developer wants to handle the 'respond' case differently they can hook into the bp_get_add_friend_button filter.

In my theme I change the button so that it is simply a link to the friend request page where the request can either be Accepted or Rejected as normal.

i.e., in the example above, when Jane looked at John's profile page she wouldn't see the 'pending' button she would see my new 'respond' button which, when she pressed it, took her to her own friend requests page where she could then quickly stab 'Reject'.

I've tested on my theme and it's working fine, not aware of any wider repercussions.

Here is the change to check_is_friend:

	function check_is_friend( $loggedin_userid, $possible_friend_userid ) {
		global $wpdb, $bp;

		if ( empty( $loggedin_userid ) || empty( $possible_friend_userid ) )
			return false;

		$result = $wpdb->get_results( $wpdb->prepare( "SELECT id, is_confirmed, initiator_user_id FROM {$bp->friends->table_name} WHERE (initiator_user_id = %d AND friend_user_id = %d) OR (initiator_user_id = %d AND friend_user_id = %d)", $loggedin_userid, $possible_friend_userid, $possible_friend_userid, $loggedin_userid ) );
		if ( !empty( $result ) ) {
			if ( 0 == (int) $result[0]->is_confirmed ) {
				if ( $loggedin_userid == $result[0]->initiator_user_id ) {
					return 'pending';
				} else {
					return 'respond';
				}
				return 'pending';
			} else {
				return 'is_friend';
			}
		} else {
			return 'not_friends';
		}
	}

This 'case' is added to function bp_get_add_friend_button in bp-friends-template.php which exactly reproduces the 'pending' case but with a different $button[id]:

			case 'respond' :
				$button = array(
					'id'                => 'respond',
					'component'         => 'friends',
					'must_be_logged_in' => true,
					'block_self'        => true,
					'wrapper_class'     => 'friendship-button pending_friend',
					'wrapper_id'        => 'friendship-button-' . $potential_friend_id,
					'link_href'         => wp_nonce_url( bp_loggedin_user_domain() . bp_get_friends_slug() . '/requests/cancel/' . $potential_friend_id . '/', 'friends_withdraw_friendship' ),
					'link_text'         => __( 'Cancel Friendship Request', 'buddypress' ),
					'link_title'        => __( 'Cancel Friendship Requested', 'buddypress' ),
					'link_id'			=> 'friend-' . $potential_friend_id,
					'link_rel'			=> 'remove',
					'link_class'        => 'friendship-button pending_friend requested'
				);
				break;

This is the first time I've contributed anything (to anything) so if I'm not following procedure, apologies...

[terraling]

Correct updated version

[terraling]

Of course, in my haste to make my first contribution I left a bit of redundant code in place in bp-friends-classes.php.

The correct version has been uploaded with the definition of check_is_friend as follows:

function check_is_friend( $loggedin_userid, $possible_friend_userid ) {
		global $wpdb, $bp;

		if ( empty( $loggedin_userid ) || empty( $possible_friend_userid ) )
			return false;

		$result = $wpdb->get_results( $wpdb->prepare( "SELECT id, is_confirmed, initiator_user_id FROM {$bp->friends->table_name} WHERE (initiator_user_id = %d AND friend_user_id = %d) OR (initiator_user_id = %d AND friend_user_id = %d)", $loggedin_userid, $possible_friend_userid, $possible_friend_userid, $loggedin_userid ) );
		if ( !empty( $result ) ) {
			if ( 0 == (int) $result[0]->is_confirmed ) {
				if ( $loggedin_userid == $result[0]->initiator_user_id ) {
					return 'pending';
				} else {
					return 'respond';
				}
			} else {
				return 'is_friend';
			}
		} else {
			return 'not_friends';
		}
	}

[terraling]

Btw, it is pretty straightforward to alter the code to change the behaviour of the button in the proposed 'respond' case so that it simply links to the user's friend request page, and I'm happy to do that.

Changing it so that the user responds then and there to the request means two buttons ('Accept' and 'Reject') which might mess with people's layouts where they have previously allowed for one.

[boonebgorges]

For the sake of simplicity, I'm going to (a) leave the "Cancel Friendship Request" button as it is (ie, it's a link that immediately cancels the pending friendship request), and (b) make the recipient's button read "Friendship Requested" and point it toward the user's friend request page. This means that there'll be a slight inconsistency in the UX, but I bet no one will notice (and it's better than adding separate "Accept" and "Reject" buttons to the directories).

Thanks for the contribution. In the future, it'd be great to get contributions as Subversion patches. That means doing your development on an SVN checkout of BuddyPress, and then generating a patch using the svn diff tool. More can be found at ​http://make.wordpress.org/core/handbook/submitting-a-patch/ and ​http://make.wordpress.org/core/handbook/svn/ (these refer to WordPress itself, but BP uses the same tools). But it's not too important, as we're delighted to have contributions in any form :)

[boonebgorges]

In 7374:

Rework "Cancel Friendship Request" button UX in member directories

Member directories have friendship action buttons for each user: notably,
Add Friend for non-friends and Remove Friend for existing friends. When
A has sent a friendship request to B, the button becomes "Cancel Friendship
Request". However, it makes no sense for B to see the same button text for
the pending request, since it's not hers to cancel.

This changeset makes it so that B will see "Friendship Requested", and
the button will lead to B's Friend Requests page, so that she can accept
or reject the request using the latter existing UI.

Fixes #5157

Props terraling