Skip to content

Adjusts pending members to be distinct

Vijay Hawoldar requested to merge vij-unique-pending-members into master

What does this MR do and why?

We are in the process of introducing a new feature for User Caps which puts Member records being added to a group in an awaiting state if the number of billable members within a group hierarchy is greater than or equal to the assigned user cap value.

We return these pending/awaiting members via the API for approval by a group admin.

This endpoint does not currently cater for the fact that there maybe multiple pending/awaiting member records for a single user, because they can be added to multiple groups within the hierarchy.

This MR addresses the problem by ensuring we return distinct results based on user ID or invite email (to cater for non-existent users who have been invited to the group)

Refs #348549 (closed)

How to set up and validate locally

  1. With a group hierarchy similar to: 
         Group A 
      /  \
 Group B  Group C
  2. Add a user to Group B and Group C
  3. Update those member records to be awaiting for testing purposes: 
      Member.last(2).map &:awaiting!
  4. Hit the API endpoint and see only one member record returned for the user: 
    curl --request GET \
--url http://127.0.0.1:3000/api/v4/groups/group-a/pending_members \
--header 'PRIVATE-TOKEN: <your token>' \

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