When an employee leaves a company, it can be quite manual and tedious to remove their access from GitLab if the user is a member of several groups/subgroups/projects.
Target audience
Group owner
Proposal
On the list of users occupying seats in the subscription, add a button to completely remove the user from the subscription (all groups/subgroups/project).
Potential issues
Removing a user who is the only owner (or only member) of a project may cause the customer to lose access to that project. If we decide to offer this functionality, we should make sure that this is clearly communicated to the customer.
@rhardarson this could be a good Stretch for %13.7. I'll leave it in %13.8 for now, just bringing awareness in case you are looking for more work. Note, this is not weighted.
@amandarueda Just a note that we don't actually have designs for this. The designs shown were just concepts. We're probably going to want to think through the implications of a "remove" action that could have such major impact (see the Potential issues section).
@mnearents sure! Most notably would be when a user is terminated from a company they would want to remove all access to their namespace (group/projects) and subscriptions management (CustomersDot) where relevant. Do you want to know all use cases or just one?
@amandarueda but wouldn't removing the owner make it so no one owned the subscription and therefore couldn't do admin things? Or would there be multiple owners in your scenario?
Removing a user who is the only owner (or only member) of a project may cause the customer to lose access to that project. If we decide to offer this functionality, we should make sure that this is clearly communicated to the customer.
Trying to see if there's a valid use case for removing the only owner, otherwise we shouldn't even allow it.
@mnearents Ah, I see the confusion, yes, there are typically multiple owners. In fact, you couldn't get into a use case of a single owner being removed unless GitLab has actually blocked that user for abuse or something. Another user cannot remove an owner unless they themselves has a role of owner.
@amandarueda just received a customer request to remove 184 members from a subscription. I won't be able to do the deletion, but I will need to manually find these users and list their location. The customer will then need to go and delete those users individually. In other words, this feature will be awesome once it's available
@rhardarson@csouthard I believe this has a frontend and backend component. Is that right? And if so, do you want two issues for this (one for each team) or do you want to work from the same issue?
@amandarueda Yes, you're correct about this requiring both frontend and backend effort. I tend to prefer splitting up frontend from backend just so it's clear who's doing what, but I can be flexible and defer if it's easier to track a single Deliverable issue.
For the backend, the weight is probably a 3 given that we're looking at probably a new endpoint, maybe an update to a service (or new service), tests, docs.
Hey @csouthard thanks for the feedback and questions.
Are we just disassociating a user from a the subscription and the group holding the subscription top-down, correct?
Yes, you are just removing the user from having membership of the root namespace and any subgroup/project beneath the root namespace.
User remains intact?
Correct, we are not doing anything to the user record, just removing membership.
Any caveats like if the they're trying to remove a group owner, or the user that purchased the subscription?
Great question! There are caveats, but they will not be addressed by this iteration.
In production today, a group owner can perform this action with only one restriction which we'll need to persist (will explain below), but they have to find the member everywhere they appear and remove them. This change is to allow the owner to remove the member from this single place and that will cascade the removal throughout the namespace.
In a future iteration we'll create warnings and blockers for when removing a user (ex. a subscription owner) will cause damage.
The one current restriction in production is that there must be an owner of a group, so we shouldn't allow a situation where the only owner of a group is able to be deleted from this page.
Is subscription functionality present in self-hosted? If so, does this need to work differently for self-hosted, or at all? Scoped to just SaaS?
This is SaaS only. We do not have such a page (Seat Usage) in self-managed. However this concept is stolen from the self-managed Users page as a concept.
Amanda Ruedachanged title from Allow group owners to remove users from the subscription to BE: Allow group owners to remove users from the subscription
changed title from Allow group owners to remove users from the subscription to BE: Allow group owners to remove users from the subscription