Skip to content

Add auto_renew to gitlab subscriptions

What does this MR do?

It introduces the concept of auto_renew to gitlab subscriptions. This will eventually enable us to present a user interface for users based on if they're auto-renewing or not. We're leaving the column nullable as a means to eventually migrate relevant data in from the subscription data from the customer portal.


We intentionally leave these columns allowing null, and with no default. Odd, right, considering it's a boolean? Well, we'll be writing some front end logic around this to remind users when they might be ending their subscription if they have auto-renew off, and potentially as a minor notification that it will renew (when true). So we're going to be using null as unknown for now, and will write some rake tasks in the customers application to push this information in, but we need to keep this "unknown state" until we get to that, and probably leaving legacy subscriptions as unknown (though we could have some discussion around this when we get there -- setting everything null to false and then "not nulling" these columns).

Additionally, when this property changes, we'll be pushing it through to the gitlab_subscription record from now on as well. I'm viewing it as a slow 3 phase migration potentially, since it'll be so hard to get this data propagated.

Why not default to true?, well, we may want to say nice things when we know they're set to auto-renew, and we might be inaccurate with the assumption.

Does this MR meet the acceptance criteria?

Conformity

Edited by Jeremy Jackson

Merge request reports