"Service account" counted as billable user in overage check when adding to group
Summary
When following the current documentation for creating a Service Account on GitLab.com, the overage check that happens when you Add a service account to subgroup or project seems to count the service account as billable.
Steps to reproduce
- Have GitLab.com namespace that is using max seat count or already has overage
- Follow instructions to create and add service account to the namespace
- Observe that upon trying to invite the account to a group, the overageModalInfoWarning pops up and warns you that continuing would incur additional costs
- Ignore the warning and proceed
- Observe no actual change in your used seat numbers
Example Project
The namespace where this was observed can be seen in the
What is the current bug behavior?
When adding a service account to a group, it is counted as a billable user in the overage check.
What is the expected correct behavior?
When adding a service account to a group, it is not counted as a billable user in the overage check.
Relevant logs and/or screenshots
This is what the customer saw when attempting to follow the process. 179 is correct, and they are currently at 183 max used seats – so already having overage of four seats. After ignoring the warning at my request, they are still at 183 max used seats.
Output of checks
This bug happens on GitLab.com
Possible fixes
It looks like the frontend is querying the getBillableUsersCount
GraphQL endpoint for this check. Last year, in Add willIncreaseOverage to billableUserChange (!105355 - merged) a willIncreaseOverage
item was added to the response of that endpoint. Very recently, Increse billable users when using custom roles (!135627 - merged) added a new increase_billable_members_count?
method. Generally it seems that the code in this endpoint is not "service account"-aware.
In Backend for Service Account MVC (!110656 - merged) we added a service_account?
condition to using_license_seat?
(but not using_gitlab_com_seat?
) – but it's not fully clear to me if that code is (or should be) used in the GraphQL endpoint above.