Skip to content

Fix previous license period

Corinna Gogolok requested to merge 327691_fix_previous_license_period into master

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
upload_error upload_success

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).

  1. 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.
  2. 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.
  3. 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.
  4. Create some historical data again for the second license, e.g. HistoricalData.create!(recorded_at: '2021-07-01'.to_time, active_user_count: 46)
  5. 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.

Edited by Corinna Gogolok

Merge request reports