Do not block access for ALL users when the license user limit is exceeded

[iuliabalan]

Is your feature request related to a problem? Please describe or add steps to reproduce your use case.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

• Currently, if, in the wiki the number of existing users is higher than the license user limit and there's an AD Pro active license, then all the users are all blocked out of the wiki and can't log in (so when there's at least one user created over the license user limit)

Describe the solution you'd like
A clear and concise description of what you want to happen.

• The license should always function for the users already created before the license user limit was exceeded.
• Not all users should be blocked, the existing users should still be able to login. Only users that are were created after the license users limit was reached (until a potential user limit increase or until other users are disabled from the wiki so that the license user limit is no longer exceeded)

[snazare]

to look into if all apps are blocked if nb of users is too big

[KebabRonin]

All apps are blocked once the number of users exceeds maxUsers. This is because the isValid() check includes a maxUsers check.

To fix this, isValid() could take into account the current XWiki Context (who is logged in).

cc @oanalavinia
Some questions for determining which users should be allowed to use the license:

Who should retain their access to licenses?

A. Take oldest active Users (sort by creationDate)

• Activating a user will revoke the license from another (newest active user) -> confusing
  • Add an info banner/notification for the user in question?

B. Take a snapshot of active users when maxUsers is exceeded

• Different licenses might have different users allowed -> confusing
• You could find a way to give license rights to different subsets of users (like allow 10 users from HR team to use Calendar app, 10 users from Dev team to use Diagram app) - should this be allowed or is it an exploit?
• How to handle exceeding the limit multiple times? (deactivating a user, then reactivating/registering a new one)
  • Take snapshot only the first time the limit is exceeded?

How to handle XWikiGuest ? Deny like the rest?

Once a license user limit is exceeded, allow guests to see the apps as long as the license isn't expired?

@michitux's idea:

Just as an idea, an alternative to allowing some users would be to have a time-based grace period. Like to say we display warnings for everybody and give a grace period of, e.g., 14 days to either disable/delete users or extend the license.

[oanalavinia]

Hi!

So an example would be the following: I have 10 users and 2 apps (diagram - license for 10 users, ideas - license for 20 users).
At some point the admin will create a new user.
Option A : The first user created from the 10 users list will not be able to use diagram anymore.
Option B: The last user created will not be able to use diagram anymore

On the functionality itself, I think option B is more intuitive, but that needs to be confirmed with others

Now on the implementation I have some remarks

Take a snapshot of active users when maxUsers is exceeded

I think you are limiting yourself by using a snapshot, which would mean a static list. If I understand correctly, you would create this list once maxUsers is exceeded.
You could instead have a list of all users, sorted based on creationDate, and depending on each app you stop at the maxUsers limit (e.g. take first 10 users for Diagram, first 20 users for Ideas). This list can indeed be cached and updated when users are created, deleted, activated,.. . I think this would answer also questions B.1 and B.3, as you don't have something static
The same might be applied for option A as well, only that you cut this list from the end, instead of from the start.

You could find a way to give license rights to different subsets of users (like allow 10 users from HR team to use Calendar app, 10 users from Dev team to use Diagram app) - should this be allowed or is it an exploit?

I think this adds more complexity that it's needed. For me, having a hierarchy based on creationDate is enough

WDYT?