[buddypress-trac] [BuddyPress Trac] #7078: Groups: Replace `BP_Group_Member` static method DB queries with updated group membership functions

[buddypress-trac]

#7078: Groups: Replace `BP_Group_Member` static method DB queries with updated
group membership functions
--------------------------------+------------------
 Reporter:  r-a-y               |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  2.6
Component:  Component - Groups  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |
--------------------------------+------------------

Comment (by dcavins):

 @r-a-y: Nice!

 I'm wondering about where the logic should actually live for the request
 and invite functions, since now we have two functions and a static method
 for each type that do similar things.

 @boonebgorges: Would it architecturally make sense to move the logic from
 your new function `groups_is_user_invited()` to
 `BP_Groups_Member::check_has_invite( $user_id, $group_id, $type )` and let
 both `groups_is_user_invited()` and `groups_check_user_has_invite()` use
 the underlying logic? (I think the difference between them is that one
 allows the `$type` param and the return values are slightly different.)

 Same for `BP_Groups_Member::check_for_membership_request( $user_id,
 $group_id )`, `groups_is_user_pending()` and
 `groups_check_for_membership_request()`? I know part of the reason for
 your new functions is so that the function naming scheme is not parallel
 otherwise.

 What's the clever way to have all of these pieces work together without
 repeating logic? Should we be deprecating
 `groups_check_for_membership_request()` and
 `groups_check_user_has_invite()`(and the underlying static methods) in
 favor of the new functions?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7078#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac