Skip to content

Fixes logic for when we reset subscription seats

Vijay Hawoldar requested to merge vij-adjust-new-term-logic into master

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

  1. In a rails console, find a GitlabSubscription record: 
    gs = GitlabSubscription.last
  2. 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)
  3. 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.

Edited by Vijay Hawoldar

Merge request reports