## Problem to solve SaaS customers are being surprised and taken off-guard by Quarterly Subscription reconciliations. Because self-service SaaS customers have not historically been charged true-ups, the QSR process and the fact that they have to pay for overages is totally new. See tickets from customers [here](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/337). ## Intended users - Group Owner or project Owner / Maintainer who adds additional members to a subscription, increasing the seat count - :white_check_mark: Group Owner that purchased a subscription for the group ([released on 2022-12-19](https://gitlab.com/gitlab-org/gitlab/-/issues/350265#note_1214362933)). - :white_check_mark: All Group Owners / Maintainers ([released on 2023-01-19](https://gitlab.com/gitlab-org/gitlab/-/issues/386281)). - Only groups enrolled in quarterly subscription reconciliation. See exactly which use cases we're solving for in the [Epic description](https://gitlab.com/groups/gitlab-org/-/epics/7230#intended-users). ## Proposal When a Member or Group is being added that would **increase** the subscription's `Seats owed` number, show a second modal and ask the user to confirm that this action will result in additional charges before actually adding the Member. Some tricky use cases to keep in mind: - If the user (or users in a Group) being added as a Member(s) is already occupying a seat in the subscription, then the modal **should not** be shown - If on Ultimate, guest users **should not** trigger the modal because guest users do not occupy a seat - If the Member is being invited via email (not GitLab username) and that email address is not already occupying a seat in the subscription, then the modal **should** be shown. The Member being invited will not actually occupy a seat until they accept the invitation from their email (pending members don't occupy seats), but once they do accept the invitation they would occupy a seat immediately, so the user inviting them should be warned that they are taking an action that will trigger an overage. <details> <summary>Some examples of when the modal would and wouldn't be shown</summary> Imagine that `Acme Corp` is your top level group. You invite `Group A` to `Project 1`. Let's assume that I have already exceeded my seat count (I'm at 12/10 seats in use). * If the members of `Group A` are already a part of `Acme Corp`, then it would not increase the `seats owed` number and the modal wouldn't be shown. * If the members of `Group A` were not already a part of `Acme Corp`, then the modal would be shown as the `seats owed` number would be increased. * Another possible situation is that part of the members of `Group A` are part of `Acme Corp` and part of the members are not. In this case, the modal would be shown because the members of `Group A` who are not currently a part of `Acme Corp` would increase the number of `seats owed`. </details> #### Design [Design here](https://gitlab.com/gitlab-org/gitlab/-/issues/347265/designs/Modal_that_informs_users_of_additional_charges_before_adding_a_member.png) When the modal that informs users of additional charges is shown, we should have a smooth transition in between the two modals. See the prototype below for details of that interaction. | If inviting user **WILL NOT** increase the number of seats owed | If inviting user **WILL** increase the number of seats owed | | ------ | ------ | | [Kapture_2022-01-27_at_11.57.09](/uploads/7270b15d66b67435f2f3942cb5bf6fe3/Kapture_2022-01-27_at_11.57.09.gif) | [Kapture_2022-01-27_at_11.56.39](/uploads/8f5a4d782c158210313a7031869e1091/Kapture_2022-01-27_at_11.56.39.gif) | _Note from @esybrant: There are no changes to the Invite members modal. Any differences you see in the prototype are just because I had to recreate that modal in Figma to make the prototype._ Original issue https://gitlab.com/gitlab-org/gitlab/-/issues/348486 ### List of cases when we show/hide overage modal | Case | Is it implemented? | | ------ | ------ | | Show overage when added users increase `seats_owed`| :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80187 | | Show overage for users added by id and by email | :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80187 | | Exclude already billed users from overage check | :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80187 | | Don't show overage on free plans | :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80187 | | Show overage for groups addition | :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81039/ | | Don't show overage if a group is not included into reconciliations | :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87284 | | Don't show overage when adding guests to Ultimate group | :white_check_mark: | This work was partially started in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/35683) over a year ago. See comment [here](https://gitlab.com/gitlab-org/gitlab/-/issues/35683#note_317205647) for status of work completed and work still pending, we may be able to use some of the completed work.