BE: Clarify membership via Invited Group
Summary
In #217851 (closed) we introduced the ability to remove users from the root namespace and perpetuate that removal in nested subgroups and projects.
Through the original report (below) we learned that this feature cannot be made available for users who have been invited to a group via an group invitation.
As a result, we should update the Seat usage page to make clear when a billable member was added to the namespace through group invitation.
Success Criteria
Note these tasks can be broken into two issues or multiple MRs on this single issue, deferring to dev
-
if a member is invited via group share that prevents removing them, the error message should state that -
the seat usage view should highlight membership via shared groups
Designs
Retaining original issue description from bug report
Summary
It was reported that attempts to remove a billable member via the Settings > Billing > See Usage page does not remove the billable member despite a user was successfully removed
message. In the following example, the user in question is listed on the seat usage
page despite not belonging to any subgroups or projects.
Steps to reproduce
- Navigate to the seat usage page and search for a user to remove
- Use the
Remove User
option to remove the billable member - Observe the
user was successfully removed
message - Refresh and confirm the user still exists as a billable member
Example Project
NOTE: I was unable to replicate this with a test user added to a test project.
What is the current bug behavior?
When a billable member is removed via the Seat Usage page, the billable member remains listed on the seat usage page despite confirmation that it was removed.
What is the expected correct behavior?
When a billable member is removed via the Seat Usage page, it should no longer be listed on the Seat Usage page and should be removed from all subgroups/projects.
Relevant logs and/or screenshots
Note: The logs show an API call to DELETE
the billable member. However, the member in question remains in both the UI and the Members API.
Output of checks
This bug happens on GitLab.com
Availability & Testing
Given that this change will likely only be a frontend , UX change, the only tests that will be required are frontend specs that test the error message(s). Since this is more of a feature gap, I don't see much necessity for an End-to-end test.
If we decide to close this gap in the future, I believe an end-to-end test will be necessary.