feat(subscription): support per-subscription seats limit

[tdrivas]

This PR introduces support for allowing seat limits in specific plans at the subscription level. To this direction a new field named max_organization_members is required for the Subscription model.

[duke-nyuki]

Task linked: QF-5474 Add support for seat based payment plans to the enduser

[gounux]

@tdrivas CI looks better now 👌

[tdrivas]

@tdrivas CI looks better now 👌

thanks! Drop and recreation of the views that are related to the migration updated fields was required.

[suricactus]

A few small comments mostly for clarity/deduplication of the code.

[suricactus]

Thanks for the review address. I have a second round of things to be done/improved.

Also, I note a few fields that you have added to the models, which is fine, but they are not presented in the Django admin. Can we expose these fields to Django admin?

[tdrivas]

@suricactus thanks for the second round of review! Changes on the admin side are also coming shortly.

[suricactus]

Here we are at a good stage, no expected changes for now, except:

1. can you reduce the number of migrations to 1 or 2?
2. I am still not convinced with is_seat_flexible naming. Don't change it for now, we can live with it.
3. probably we can move subscription.Plan.UsageType to a more billing related place.

[tdrivas]

Here we are at a good stage, no expected changes for now, except:

1. can you reduce the number of migrations to 1 or 2?
2. I am still not convinced with is_seat_flexible naming. Don't change it for now, we can live with it.
3. probably we can move subscription.Plan.UsageType to a more billing related place.

Thanks for the fruitful review.

1. Done
2. Yep, lets live with it for now
3. Finally, I moved the entire field to a more billing related place without breaking anything here.

[suricactus]

@tdrivas can we make the CI happy again?

[tdrivas]

@tdrivas can we make the CI happy again?

Thanks a lot @suricactus for the contribution on the migration issue. Checking now for other issues on CI.

[suricactus]

I am still not convinced this is the right way to go: two queries in one migration step.

If this is the only way to go, please add a

NOTE: while suboptimal to run two queries per migration step, this is the only working solution to recreate the `current_subscriptions_vw` on rollback so far.

[suricactus]

So far so good here, I will not push any more changes here.

[suricactus]

Hm, I find the logic here a bit confusing. Basically we do the following:

check if the plan has max_organization_members
AND
check if the current organization has more than the subscription max_organization_members.

Would it make more sense to check for the max_organization_members in the same model in both conditions?

[suricactus]

Closing and reopening in a new clean PR.