Handle reset_seat_statistics for ultimate-trial-paid-customer plan
This issue is to cover one action required after the research in Spike issue #423312 (comment 1646447232).
When a namespace is under Plan::ULTIMATE_TRIAL_PAID_CUSTOMER, we should continue to do seats calculation as if they are still on SaaS Premium.
Problem
Every time when GitlabSubscription is updated, there is a before_update logic which could reset_seat_statistics.
- when the trail starts, we update GitlabSubscription from
premiumplan toultimate_trial_paid_customerplan - when the trail expires, we update GitlabSubscription from
ultimate_trial_paid_customerplan topremiumplan(if it is NOT RENEWED)
We do not want reset_seat_statistics happen for the above two scenarios. Otherwise the max_seats_used will be reset and the seat calculation will be wrong.
Proposal
We can add some conditions check in the method GitlabSubscription#reset_seat_statistics?. To be specific:
- if the GitlabSubscription is not related to
ultimate_trial_paid_customer(checkhosted_plan_id_wasandhosted_plan_id), default to the existing behaviour - if the GitlabSubscription is related to
ultimate_trial_paid_customer(eitherhosted_plan_id_wasorhosted_plan_idisultimate_trial_paid_customer)
| hosted_plan_id_was | hosted_plan_id | expected behaviour |
|---|---|---|
| ultimate_trial_paid_customer | ultimate_trial_paid_customer | do not reset seat statistics |
*(it can ONLY be premium) |
ultimate_trial_paid_customer | do not reset seat statistics |
| ultimate_trial_paid_customer | premium(NOT renewed) | do not reset seat statistics |
| ultimate_trial_paid_customer | premium(renewed) | reset seat statistics |
| ultimate_trial_paid_customer | other plan(usually means upgraded to ultimate) | reset seat statistics |
Result
reset_seat_statistics works correctly for each scenario.
Next steps (if any)
How will we measure success?
Edited by Qingyu Zhao