[buddypress-trac] [BuddyPress Trac] #6090: Fix groups_join_group() & groups_accept_invite() behavior

[buddypress-trac]

#6090: Fix groups_join_group() & groups_accept_invite() behavior
--------------------------+-----------------------------
 Reporter:  dcavins       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Groups        |    Version:
 Severity:  normal        |   Keywords:  has-patch
--------------------------+-----------------------------
 I uncovered a problem with the group membership functions
 `groups_join_group()` and `groups_accept_invite()` while writing some unit
 tests. The problem is that the function
 `groups_delete_membership_request()` was being used with the parameters in
 the wrong order. It expects, in this order:
 `$membership_id`, `$user_id`, `$group_id`

 But in `groups_join_group()` and `groups_accept_invite()` we were using it
 with these parameters:
 `groups_delete_membership_request( $user_id, $group_id )`

 So it was treating the passed user id as a membership id, and, since
 `groups_delete_membership_request()` was using `BP_Groups_Member::delete`,
 the group membership record with the table id matching the new member's
 user id was being deleted. (E.g. `groups_delete_membership_request( 14, 2
 )` deletes the 14th row of the table, no matter what it represents. )
 Oops.

 I've added a "null" in the function parameter list so that the user_id and
 group_id are passed as expected to `groups_delete_membership_request()`.
 I've also changed `groups_delete_membership_request()` to use
 `BP_Groups_Member::delete_request()` which is bit more restrained than
 `BP_Groups_Member::delete`.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6090>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac