Fixes logic for when we reset subscription seats
What does this MR do and why?
In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4965 it was highlighted that when a GitlabSubscription
is updated to move a subscription from a trial to a paid subscription, the max_seats_used
were not being reset, which they should - the seats a customer use in a trial should not (always) be what they pay for when they convert to a paid customer, instead we should re-count what their current seats in use are.
This was happening because we were only checking to see if the subscription had started a "new term", i.e. that the start/end dates had changed in a way that indicated a renewal or new subscription had started.
This MR modifies the logic to also include checking the max_seats_used_changed_at
value and if it's out of date (i.e. it is before the subscription start date), then we will reset the seat statistics.
This means that if for any reason the last time we changed the max_seats_used
is before the start_date
of the subscription, we'll recalculate and update the seat statistics.
More info/context can be found in the related issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4965
How to set up and validate locally
- In a rails console, find a
GitlabSubscription
record:gs = GitlabSubscription.last
- Set some default stats for comparison:
gs.update(max_seats_used: 999, max_seats_used_changed_at: 1.month.ago, seats_in_use: 1, seats_owed: 998, trial: true)
- Test that the next update resets the seats:
gs.update(start_date: Date.today) gs.inspect # the values set above should have changed to match your local data
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.