BE: update invitations API, or create a new one, to handle invites with the approval flow

Problem

  • Pending promotion can happen to non-members and such promotion requests don't have a relevant member entry, which makes it challenging to display on the /members page since that code is heavily focused on displaying particularly members. We had to detach Promotion Requests from Members table, and thus have a breakout in /members page code to display non-members entities.

  • Now that we have made that change, we will be able to account for our 2nd user case below where we are able to account for approval of new members.

  • PS: New users (invited via Email) are already handled with the current UserCap feature(i.e they get queued for approval), and will not be dealt with as part of this change

Use Cases

Use Cases Issue Status
  1. Accounting for Role Changes of Existing Members: changing the role of existing members (users who are already member of the group but with a different role) from non-billable to billable.

#433172 (closed)

✅ Complete
  1. Accounting for New Users/New Members: when we 'invite' new users to the group.
    • New members: Invite "Existing Users" who are already existing users in the system but new to the group

✅ Complete

Work to do

  • Change the table structure to allow MemberApprovals to be independent of Members table !144882 (merged)
  • Queueing members added via the invitation API
Initial Issue Content Current flow, vs expected flow

1. A POST Request goes to "api/v4/groups/<group_id>/invitations" here, which returns with 201 created
2. The request triggers InviteService which is extended from the Members::CreateService, which then adds the user by inserting a record in the Members table.
↳ app/services/members/creator_service.rb:208:in `commit_changes'

Change flow to stop User Role Updating
1. If user role > Guest and FF enabled, queue the request in a table, and return a corresponding message from Invitations API.
2. FE changes to display "Invited or Asked to be promoted" users with their role change from X to Y, and corresponding BE changes (Should be same as Case1)

1. Users Role is changed and it is reflected to the User

1. Users Role remains the same. It should seem like nothing has happened to the Invited User

1. Currently No action on Admin

1. FE changes and corresponding BE changes to display list of "Pending promotion/Invitation" tab
2. BE changes to Approve Request which should
1. Trigger InviteService which is extended from the Members::CreateService, which then adds the user by inserting a record in the Members table.
2. Delete the request from the table.
3. Corresponding FE changes to integrate Approval Flow
Edited by Suraj Tripathi