Make sure license downgrades are supported

Dev: https://dev.gitlab.org/gitlab/gitlab-ee/issues/299

Sytse

As a customer I have:

• license for 50 in 2000 (active users go up to 95 during the year)
• license for 100 in 2001 (active users go down to 75 during the year)
• license for 80 in 2002 (active users go down to 60 during the year)

In the current situation the license upload in 2002 for 80 user will check the maximum number of users one year back. That will be the 95 at the start of 2001. It will refuse the activate the new license.

I propose that the license check not only looks at the new license but also at any existing licenses.

The logic should be as follows (examples given for 2002).

At the time of uploading a new license (Nov 21, 2001) check that the maximum number of users in the year before the start of the license (75 in the year before Jan 1, 2002) is smaller than the maximum of any (existing & uploaded) licenses that are valid (between start and expire) in the year before the start of the uploaded license (100 in the previous license is valid expires Dec 31, 2001).

In summary, at upload, check the year before start, compare most users in that year with biggest license valid in that year.

It is important that we set the issue/start/expire attributes correctly since people will upload a new license in advance of the expiration, so issue_date != start_date != date of uploading.

Douwe

I'm not completely sure what you propose; too many years, licenses and numbers going on. Some way of supporting downgrades is certainly possible, but we should call about it some time.

Sytse

This will help with downgrades, but customers that get a bigger subscription will still have the charges for last year added to their bill. Maybe it is better to solve that by setting a flag on the license. douwe indeed, this is not urgent

Job

I missing a step. What happens after comparing that? In your example:

• 95 in 2001
• 100 in 2001

Sytse

I think I was confused myself this morning, I completely rewrote the description.

DOuwe

I'm still confused :)

You write: In summary, at upload, check the year before start, compare most users in that year with biggest license valid in that year. So what happens after comparing that?

Sytse

If there are more users in the year before start than the biggest license valid in the year before start we do not accept the license. If there are less or equal users in the year before start than the biggest license valid in the year before start we accept the license.

Douwe

Thank you, I think I got it.

This will require some changes in the specific dates we include in the license, and how we work with them exactly, so we should have a discussion with all involved.

Job

it seems to me that there is a dead path in your description:

What if we do not accept the license? There is no resolve in your explanation.

You're saying that we're checking the max users in 2001 and the license in 2001. If the license in 2001 doesn't allow the max users in 2001, reject the license for 2002.

So I suppose you propose a compensation mechanism:

overage = max_users_last_year - license_last_year

if overage > new_license - license_last_year
  reject new_license
else
  accept new_license
end

Sytse

If we don't accept the new license people can't add it and have to ask us for a license with more users.

I think you pseudocode does not reflect what I tried to communicate.

I think I mean:

def upload_license_check

valid_licenses = licenses_valid_at(start_of_new_license)

maximum_allowed = max(valid_licenses.map(&max_users))

if maximum_users_year_before(start_of_new_license) > maximum_allowed
  reject new_license
else
  accept new_license
end

end

cc/ @sytses @JobV @DouweM @dzaporozhets

I wonder if this is causing an issue I've been experiencing.

I installed a trial license when I was at 154 active users. I blocked 54 users (old users that we don't need anymore) and purchased a 100-seat license, which isn't working.

mentioned in issue #232 (closed)

mentioned in commit b58f3235

Mentioned in commit b58f3235