Fix previous license period
What does this MR do and why?
Part of #327691 (closed)
Prior to this change, when applying a new license, prior historical data was looked up for the period that reponds to the license that was uploaded before the current license. Now, the current license's period is used instead. If there is no current license, then there's a fallback to the new license's starts and expires at dates from a year ago. In case the license does not have an expiration date it will use the starts at date - 1 year.
Screenshots
Before | After |
---|---|
Note: License key is not complete on screenshot
How to set up and validate locally
Setting this up requires specific data for licenses and historical data. It might be best to clear that data to not get false results or use a new setup (like a docker instance).
- Create a license valid from 2019-11-01 - 2020-10-31 for 60 users and apply it in your GitLab instance. This license is going to be the (old) previous license.
- Create some historical data for the above time, e.g.
HistoricalData.create!(recorded_at: '2020-08-01'.to_time, active_user_count: 56)
. You can create multiple entries for that period. - Create another license from 2020-11-01 - 2021-10-31 for 60 users and 56 previous users. Apply it in your GitLab instance. This license is going to be the current license.
- Create some historical data again for the second license, e.g.
HistoricalData.create!(recorded_at: '2021-07-01'.to_time, active_user_count: 46)
- Create one more license valid from 2021-10-01 - 2022-09-30 for 50 users and 46 previous users. When attempting to apply this logic without the changes it should not work and show an error message about needing more users. When applying the logic with the changes in place, it should succeed.
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.