Skip to:

Opened 5 years ago

Closed 3 years ago

#6025 closed enhancement

Add function to send single invitation

Reported by: dcavins Owned by: dcavins
Milestone: Priority: normal
Severity: normal Version:
Component: Groups Keywords: has-patch


The current send invitations function, groups_send_invites() takes an inviter ID and a group ID and attempts to send all of the non-sent invitations from that user in that group.

This patch introduces a new function, groups_send_invite_by_invitee(), that sends a single invitation keyed by the invitee ID and group ID. This is useful for sending specific invitations and resending invitations (from a group's "invitations" pane or from the group admin in wp-admin).

I'm attaching two versions: one is built on the current invitation schema, the other is built on the new schema proposed by @imath in #5911. (Short explanation: currently only one invitation to a group should exist for any invitee. Imath proposes that several users could potentially invite the same user, so creates multiple invitations--this method makes for a better user experience in my opinion, because users aren't stumped when they can't create an invitation to a group because someone else already has.)

In my "pre-5911" version, groups_send_invite_by_invitee() only requires the invitee ID and group ID (since only one invitation should exist). In my "post-5911" version, the function requires invitee ID, inviter ID and group ID (so that we send/resend the correct version).

This function is required for progress on #5336.

Attachments (6)

6025.01-pre-5911.patch (4.5 KB) - added by dcavins 5 years ago.
Does not require math's changes in #5911
6025.01-post-5911.patch (4.6 KB) - added by dcavins 5 years ago.
Requires math's changes in #5911
6025.02.patch (19.3 KB) - added by dcavins 5 years ago.
Add groups_send_invite_by_invitee
6025.03.patch (19.3 KB) - added by dcavins 5 years ago.
Add groups_send_invite_by_invitee, docs fix
6025.04.patch (11.8 KB) - added by r-a-y 5 years ago.
6025.05.patch (17.4 KB) - added by dcavins 4 years ago.
Refreshed patch

Download all attachments as: .zip

Change History (21)

5 years ago

Does not require math's changes in #5911

5 years ago

Requires math's changes in #5911

#1 @boonebgorges
5 years ago

  • Component changed from Core to Groups
  • Keywords needs-patch added; has-patch removed
  • Milestone changed from Awaiting Review to 2.2

Thanks for this, dcavins. Looks pretty good, but I have a few questions/requests:

  • I'd like to see more unit tests for the various failure conditions: empty group id, empty invitee id, invited user does not have an invite of the right sort, maybe non-existent group/user (though you don't have bail conditions for this latter part).
  • Let's return the bool value of `$member->save().
  • I understand why you're reusing the 'groups_send_invites' action, but I have mixed feelings about firing it in two different places. Can/should we rewrite one of these functions (groups_send_invites() or groups_send_invite_by_invitee()) to use the other one internally?

#2 follow-up: @boonebgorges
5 years ago

Oh, and one more quick comment: can we go with the pre-5911 patch for now, and then create a patch that can be applied when/if 5911 is resolved, which will bring it in line with that change?

#3 in reply to: ↑ 2 @dcavins
5 years ago

Replying to boonebgorges:

Oh, and one more quick comment: can we go with the pre-5911 patch for now, and then create a patch that can be applied when/if 5911 is resolved, which will bring it in line with that change?

Yes, as long as we require the $inviter_id arg now in either case, then updating for #5911 would only require the internal addition of the $inviter_id argument in groups_check_user_has_invite().

And, yes, groups_send_invites( $user_id, $group_id ) could definitely use the new function internally. I'll write it as such and add some more test cases. Re the groups_send_invites action. It would have to live in the child function (by_invitee), but its arg is an array (I made my arg array( $invitee_id ) so that it would be cast as expected). Can you think of any reason that calling it six times for six single invites would be not acceptable for some action that is expecting a cohort of invited IDs in a single array?

Re tests: I think testing for non-existent groups/users should fall to groups_check_user_has_invite() which is what I'm using to verify that the invitation is legit. I'll add some tests for that function, too.

Thanks for the quick feedback!

5 years ago

Add groups_send_invite_by_invitee

#4 @dcavins
5 years ago

  • Keywords has-patch added; needs-patch removed

This new patch modifies groups_send_invites() to use the new function groups_send_invite_by_invitee() internally.

Adding a number of tests for those functions made me think about when these functions (and the functions they rely on) should return true or false. Here are the decisions that I made in this patch:


  • Returns false when the group or member objects don't contain ids.
  • Returns false when the submitted inviter_id doesn't match the recorded inviter_id in the groups_members db.
  • Returns true if the notification has already been sent, and we haven't specified resend.
  • If it completes, it returns the result of wp_mail().


  • Returns false if the required parameters aren't provided.
  • Returns false if an invitation doesn't exist from that group to that user.
  • Returns true if groups_notification_group_invites() returns true and $member->invite_sent gets updated (or doesn't need to be)


  • Returns false if the inviter can't send invitations from this group
  • Returns true if all calls to groups_send_invite_by_invitee() return true, false if any fail

I also modified bp_groups_user_can_send_invites() to accept a $user_id. (It previously only worked off the logged-in user id.) So I added a number of tests for it as well. (I'd like to apply a bp_groups_user_can_send_invites() check to groups_invite_user() as well. I think the check is happening in the template or js file, but it seems like it should happen at the point of recording the new invite.) Since I modified it, I figured I'd better write tests for it, too.

Please let me know if these return values seem to make sense and are BP-typical.

Thanks in advance for your comments. (Especially about the new tests. I was hoping to cover the major cases, so let me know if I missed any, overdid it or just plain did it wrong.)

5 years ago

Add groups_send_invite_by_invitee, docs fix

#5 @dcavins
5 years ago

I've created a separate ticket for the addition of the user_id parameter to bp_groups_user_can_send_invites().

See #6031.

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.

5 years ago

#7 @r-a-y
5 years ago

I've committed the enhancements dcavins made to bp_groups_user_can_send_invites() from #6031.

6025.04.patch is refreshed to take this into account. I haven't reviewed the rest of this ticket yet.

Last edited 5 years ago by r-a-y (previous) (diff)

5 years ago

#8 @DJPaul
5 years ago

  • Milestone changed from 2.2 to 2.3
  • Owner set to dcavins
  • Status changed from new to assigned

I think this is too late for 2.2 now.

#9 @DJPaul
5 years ago

  • Keywords early added
  • Milestone changed from 2.3 to 2.4

:( Much sadness that I have to punt it again. @dcavins, moving this to 2.4, and we can take a look at it early.

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.

4 years ago

4 years ago

Refreshed patch

#11 @DJPaul
4 years ago

  • Keywords dev-feedback added
  • Milestone changed from 2.4 to 2.5

This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.

4 years ago

#13 @dcavins
4 years ago

  • Milestone changed from 2.5 to 2.6

#14 @DJPaul
4 years ago

  • Keywords early dev-feedback removed
  • Milestone changed from 2.6 to Future Release

@dcavins I have no idea what is going on with this ticket, but I've moved it into future release. If you want to progress it, please refresh the patch, and re-summarise what it does and what the next steps are. Thanks.

#15 @dcavins
3 years ago

  • Milestone Future Release deleted
  • Status changed from assigned to closed

This work will happen as part of 6210. At this point, this ticket should be considered a duplicate.

Note: See TracTickets for help on using tickets.