Skip to content

Modify pending member approval endpoint

Vijay Hawoldar requested to merge vij-modify-approve-member-endpoint into master

What does this MR do and why?

We recently added a new endpoint for approving pending members for a group.

The requirements for the pending members have shifted slightly to also include invited members, which are Member records for users who have not yet signed up (i.e. invited to a group or project by email address).

This means that the endpoint needs to change to use member_id rather than user_id, as not all requests to this endpoint will have a user ID yet.

What's changed?

  • Endpoint params changed from user_id to member_id
  • Endpoint now looks up a Member rather than a User
  • ActivateService changed to support Member instead of User (params, queries, logs)
  • ActivateService additional validation (missing member param) and spec coverage (multiple member records in hierarchy)

It's worth noting that this endpoint is as yet unused, the feature flag is disabled and no users should be making use of it - so we shouldn't need to consider this a breaking change for the API.

How to set up and validate locally

  1. Make a member pending/awaiting 
    Member.last.wait!
Member.last.awaiting?
=> true
  2. Hit the API endpoint for that member's group/user 
    curl --request PUT \
--url http://127.0.0.1:3000/api/v4/groups/:group_id/members/:member_id/approve \
--header 'PRIVATE-TOKEN: <your token>' \
  3. Verify the change 
    Member.last.active?
=> true

This can also be tested for an invited member, by inviting a non-existing user to the group and performing the above steps with the relevant member record.

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