[buddypress-trac] [BuddyPress] #5032: Sending group invite to member that has requested group membership doesn't work

[buddypress-trac]

#5032: Sending group invite to member that has requested group membership doesn't
work
-----------------------------------+------------------------------
 Reporter:  Mike_Cowobo            |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Groups                 |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------------------
Changes (by Mike_Cowobo):

 * cc: mike@… (added)


Comment:

 I don't think you are over thinking this, as this would actually solve a
 greater annoyance, namely that users still see 'Request Membership' when
 they're already invited.

 You're right that changing the button (a) would entail an extra walk to
 the db for every private group a user is not a member of yet. This is
 silly, because the only real difference between a request and an invite is
 that invites have an inviter ID and requests do not. I have collated these
 checks into a method `BP_Member::get_invites_and_requests()`, which is
 called by `groups_check_for_membership_request_and_invite()`. Checking for
 either then boils down to `$membership_status['has_invite']` or
 `$membership_status['has_request']`.

 For a group admin inviting a user (b), I'm not sure if that is so straight
 forward, or necessary for that matter. What happens now, is that when an
 admin selects a friend to send an invite to, the invite is created in the
 db in the ajax call, but not sent until the admin clicks the 'Send
 Invites' button. If a user has requested membership, this request has to
 be accepted before the invite is added to the db. Changing this behaviour
 would entail either changing the response from the ajax call (perhaps a
 separate listing for users-with-membership-requests, with a 'Accept
 Request' button) or adding separate logic for membership-request users (no
 new invite is created, but when invites are sent, membership requests are
 accepted). I think this is overdoing it for such a rare event.
 Better alternative is perhaps accepting the request when the invite is
 made, and returning a notice about how and why the user is now a member of
 this group, instead of adding her to the invite list...
 (Or.. we could filter the friend list to simply not show users that have
 an outstanding membership request to this group, and completely prevent
 this from happening in the first place..)
 (Or am I over thinking this?)

 The message shown to a user when she has accepted an invite (c) does not
 have to change if (a) is implemented: the buttons will already read
 "Accept Invitation", and notifying the user that "Because you were already
 invited [...]" is plain redundant. Only scenario in which this could pose
 a problem, is when a user is on a view with a 'Request Membership' button,
 gets invited by somebody, and clicks 'Request Membership'. She will get
 notified that she has accepted the group invitation. But she will also
 still have a 'You have been invited ...' message in her notifications. So
 it should be alright anyway..

 Then, lastly, everything now happens through the 'request-membership'
 action, because in groups, it is quite deeply entrenched as an exception
 to the access check for non-members. Adding accept-invite would just add
 clutter. Also, the scenario in the previous paragraph is caught exactly
 because of this.

 In the patch I changed the label for the 'Request Membership' tab to
 'Accept Invitation' when a user has a pending invite. However, accepting
 an invite through group_slug/request-membership is now not nonced, because
 then we'd need to add another screen for accepting invites. Currently,
 navigating to the 'Accept Invitation' tab in the group results in
 accepting the invitation. Because there is nothing else to do when
 accepting an invite (like adding a comment), it seems highly redundant to
 add yet another screen ("You are about to accept the group invitation!")
 with just another 'Accept Invitation' button on it (while the user could
 just have clicked the 'Accept Invitation' anywhere!)

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