Skip to content

Add a new endpoint for pending members

Vijay Hawoldar requested to merge vij-all-pending-members-api-endpoint into master

What does this MR do and why?

  • adds a new entity, PendingMember to represent Member records in an awaiting state and/or invited (no user account yet)
  • adds an API endpoint to list pending members, GET /group/:id/pending_members
  • adds scope to EE::Member to fetch the records matching the criteria above

We need these changes in order to support the FE effort for rendering pending members within the usage quotas page, so that when a namespace reaches it's user cap (WIP epic), an owner can approve pending members.

This is slightly more complicated than perhaps we would have liked, because we also need to cater for members who have been invited by email (no user account).

These members need to be able to be approved, but remain in the pending members list until the user has signed up/accepted the invite as shown in the FE requirements here: #321934[rt-group-owner-approved-awaiting-signup.png]

Refs #332596 (closed) and #333064 (closed)

Documentation has been split out into !75232 (merged)

How to set up and validate locally

  1. Setup a Group (e.g. Test Group A)
  2. Setup a Subgroup (e.g. Test SubGroup)
  3. Add a member to both groups
  4. Invite a user who has not signed up, to one of the groups

Without the saas_user_cap feature setup, we'll need to manually adjust their states to pending/awaiting:

 Member.last(3).map &:wait!
 => true

Hit the API endpoint for the root group (Test Group A)

 curl --request GET \
 --url http://127.0.0.1:3000/api/v4/groups/test-group-a/pending_members \
 --header 'PRIVATE-TOKEN: <your token>' \

You should see all 3 members.

Next, activate the members:

 Member.last(3).map &:activate!
 => true

Hitting the API endpoint again, you should only have the invited user returned (with approved: true).

Lastly, accept the invite for the invited member and hit the endpoint again, there should be no results.

 Member.last.accept_invite!(some_user)
 => true

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Vijay Hawoldar

Merge request reports