Skip to content

Draft: Include awaiting members for billing

Nicolas Dular requested to merge nd/free-user-cap-show-members into master

What does this MR do and why?

This MR is a Draft to start a discussion about changing the scope and it's intended and unintended side-effects.

Why do I want to change the scope?

For the free-user-cap work we use the AWAITING state for Members which get capped. e.g. a group with 8 free users gets capped at 5 users, and we set 3 of these users as AWAITING.

We excluded "pending" members for billing just recently, however for this specific case, we want to set the minimum amount of used seats that includes these pending (= state AWAITING) members.

What does this change of scope would solve

  1. We want to give owners of the group the ability to change which member uses the seat for the free-user limit, see https://gitlab.com/gitlab-org/gitlab/-/issues/352638+. Currently the usage quota seat page is using a billable_members API, which does not include the AWAITING members. It would require a API param or even a different API to display AWAITING users.
  2. When a group with 8 users (5 active, 3 awaiting) goes to purchase seats for the group, the minimum quantity should be 8 - which is currently not the case, but would be accounted for with this change.

Concerns

I am concerned that this scope is used widely and has a larger impact that I can't see right now, hence it got introduced just recently for a reason. So I'd like to know

  1. Which side-effects this would introduce that could be problematic
  2. How we could overcome them?
    1. E.g. would it make sense to only account for AWAITING users in the scope when the namespace is on the free_user_cap?

Describe in detail what your merge request does and why.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Nicolas Dular

Merge request reports