## 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 - 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 | | ------ | ------ | | [Prototype link](https://www.figma.com/proto/BQTLTBijUHuadEoJPKgZDX/Communicating-QSR-and-related-charges-to-Owners-and-users?page-id=2%3A51&node-id=151%3A15934&viewport=337%2C48%2C0.13&scaling=min-zoom&starting-point-node-id=151%3A15934&show-proto-sidebar=1)<br>  | [Prototype link](https://www.figma.com/proto/BQTLTBijUHuadEoJPKgZDX/Communicating-QSR-and-related-charges-to-Owners-and-users?page-id=2%3A51&node-id=138%3A11728&viewport=337%2C48%2C0.13&scaling=min-zoom&starting-point-node-id=138%3A11728&show-proto-sidebar=1)<br>  | _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._ ## Implementation plan | Step | Status | |------|--------| | Add a modal for user addition window behind a feature toggle ~frontend | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79644 ~"workflow::staging" | | Set the transition between two components ~frontend | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80187 ~"workflow::in review" | | Calculate conditions when we should show a modal ~backend | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78287 ~"workflow::in review" | | Add a overage check on inviting a group ~frontend ~backend| https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81039/ ~"workflow::in dev" | | Rollout the feature flag | https://gitlab.com/gitlab-org/gitlab/-/issues/350265 ~"workflow::blocked" | ### 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 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81039/ :hourglass: | | Don't show overage if a group is not included into reconciliations | :hourglass: MR TBD | | Don't show overage when adding guests to Ultimate group | :hourglass: MR TBD | 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.