Add Billable Member deletion API endpoint
What does this MR do?
We recently added the ability for our customers to remove billable members from the root group (#301232 (closed)), which should stop them from using a seat, by removing them from the group, sub-groups and projects, too.
Initially this was implemented using the existing member deletion API endpoint, but this has caused a problem when trying to remove direct project members (#323087 (closed)) who are not a member of the parent group.
A user can be directly associated to a project, but not the parent group, but they still count as using a seat and so can be viewed as a billable member and subsequently removed.
The problem is that the frontend doesn't know what the user's relationship is to the group, and will only have the root group to use when querying the API, but the existing endpoint will only look for direct GroupMember associations when a group is passed to it, thus throwing a 404 for users who only have a ProjectMember association.
This MR seeks to address the problem by adding a new endpoint for this purpose, whereby the user will be found within the hierarchy of the given group, and then removed (using the same service), which caters for both GroupMembers and ProjectMembers (direct or inherited).
Testing
Firstly, add a user directly to a project (not via a group)
Via the UI:
- Visit the seat usage page for the parent group, e.g.
http://localhost:3000/groups/group-name/-/seat_usage - Remove the user from the group
Via the API:
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/:id/billable_members/:user_id"Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because _____.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team