[buddypress-trac] [BuddyPress Trac] #6210: Create New Invitations API

[buddypress-trac]

#6210: Create New Invitations API
---------------------+-----------------------------
 Reporter:  dcavins  |      Owner:
     Type:  task     |     Status:  new
 Priority:  normal   |  Milestone:  Awaiting Review
Component:  API      |    Version:
 Severity:  normal   |   Keywords:  dev-feedback
---------------------+-----------------------------
 Create a flexible API to create/retrieve invitations across components.

 ** Examples:

 • invite to a group
 • invite to the site
 • invite to a blog
 • invite to edit a doc

 ** Tasks:

 • Write tests for group invitations. (See #6209)
 • Write core invitations API code.
 • Switch group invitations over to using invitations API.
 • improve group invitations experience
 • Add new features.

 --------

 **Data structure

 On one hand, it makes sense to use a dedicated table for this like we do
 with notifications, but it could easily be built using a new custom post
 type and post meta (since Boone’s been souping up `WP_Query`'s meta
 queries...)

 I would really appreciate some feedback on which way BuddyPress wants to
 go with future data and the positives of each approach.

 If a table, here are the fields I’m imagining:
 `id` - primary key
 `user_id` - ID of invited user, maybe 0 if invitee is not a site member
 `inviter_id` - ID of user that created invite, maybe 0 if a request for
 membership
 `invitee_email` - used when invitee is not yet a member of the site
 `component_name` - e.g., groups, similar to activity/notification
 `component_action` - to cover components that need several invitations
 `item_id` - e.g., group id in the case of a group invitation
 `secondary_item_id` - flexibility for components
 `content` - store extra information provided by inviter/requester
 `date_modified` - date created or date invite sent
 `invite_sent` - 0 if draft, 1 if sent.
 `opt_out` - Has this user asked to receive no more invitations from a
 component?


 **Group Memberships

 Currently, outstanding group memberships are stored in the group members
 table and identified via a combination of statuses. I’m thinking that
 users who have been invited or have requested membership would exist only
 in the new invitations table.


 **Areas for improvement/Adding new features

 • Allow multiple invitations to a group from different users, as imath
 proposed—this helps with transparency.
 • Allow site admins to decide if members can only invite friends to groups
 (current behavior), or if users can invite any site member.
 • Apply the new suggestions API to the group invitation pane. (Can it be
 extended to display status messages like “Violet Vance — already a
 member”?)
 • Allow invitation of non-site members to the site and groups, like Invite
 Anyone.
 • Maybe provide centralized invitations pane for user with status. Could
 be a new tab, or maybe should be under some other tab—there are a lot of
 navigation options on the user’s profile already—could  notifications
 about invites contain actions for responding to invitations/requests?
 • Improvements to invitations UI so that it’s clear what status each
 invitation has—draft, sent (and when)—and the ability to resend.
 • Improved invitation management for group admins and site admins (via wp-
 admin groups management pane).

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