[Product: Problem Validation] Seat Usage Quotas: Make Billable Member Addition History Trackable
Iteration Plan
- Iteration 1: show user's invited group &13762 (closed) -- further described here
- Iteration 2: show user's invited project &13763 -- further described here
Requirements
Background
What context do we need?
- This issue Show project that invited group users on usage ... (#351954 - closed) has been open for many years
😅 - There are multiple ways to gain indirect access to a group via sharing:
What is the problem?
- Admin & owners will be trying to audit their billable users. They will come across a user that is part of their billable members list because they (unknown to the admin/owner) were added via project/group sharing. The admins/owners want to know how/why that user became billable. Since the user won't exist as a direct member, the owner/admin will be unable to actually remove this user without first removing the group.
Why does the problem occur?
- It is very difficult to know which group the user is part and where that group is shared.
- Additionally, currently, the billable members API only works for direct memberships, so you'll be unable to find this information using the API.
Who does the problem impact?
- Group owners / admins trying to audit their billable users.
Are there any workarounds to this problem?
- Support is utilizing a console script to find this type of information for customers.
What are some examples of this problem?
- https://gitlab.zendesk.com/agent/tickets/266231
- https://gitlab.zendesk.com/agent/tickets/218962
- https://gitlab.zendesk.com/agent/tickets/282855
- https://gitlab.zendesk.com/agent/tickets/292695
- https://gitlab.zendesk.com/agent/tickets/300033
- https://gitlab.zendesk.com/agent/tickets/299951
Design Plan
What is the solution concept?
- Give admins/owners of top-level groups the ability to understand how/where a user became billable via showing them:
- the invited group because that's the group that needs to be removed (if the admin/owner choose to remove the user via disconnecting the group) and/or
- the project to know where to go to remove the invited group.
- On the Usage Quotas
Seats
page we will be able to expand upon each billable users and see:- [Iteration 1] If the seat is through a group invite, we can list the invited group in the seats page, this way the admin can see the group and go to the group and remove that user.
- If the seat is through a project invite (assuming we have structure like in the image below), the admin has 2 options to remove the seat:
- [Iteration 1] the admin removes the user from the Group B (problem solved)
- [Iteration 2] the admin doesn't want to remove the user from Group B (for any management reason) but instead wants to remove the whole Group B from accessing the project
What does the feature look like?
Where would we solve for this?
- At the top-level-group on the Usage Quotas
Seats
page
Who would be have access to this feature?
- Offering & Tier: All GitLab.com & Self-Managed customers across all tiers: Free, Premium, and Ultimate
- Role: Owners
Is this feature "on" by default?
- Yes.
Edited by Alex Martin