requestAccess should optionally not enter grace period

[pekam]

The requestAccess method registers the provided user for the current month if the user was not yet registered and the license quota allows registering a new user. This can be used to check if collaborative features can be enabled for an end user and build the app accordingly.

For example, disable parts of the UI that use collaborative features:

Button button = new Button("Open collaborative view");
button.setVisible(false);
CollaborationEngine.getInstance().requestAccess(UI.getCurrent(), user,
        hasAccess -> button.setVisible(hasAccess));

If the quota is 10 and the user to request access to is 11th monthly user, the method will enter grace period and resolve with hasAccess=true.

This method can be thought of as a backup plan if things go wrong, but it's also possible that the developer thinks: "I have quota of 10 users. I don't want to buy a license with a bigger quota although I know that I may have more than 10 monthly users. I just want to enable collaborative features for the first 10."

In that case, it would be nice to just resolve with false if the normal quota is full, and not enter the grace period. When it's expected that the quota is exceeded on a monthly basis, it would be good to keep grace period as a backup, instead of wasting it on the first month.

One potential solution might be adding an optional boolean parameter to the method. Another question is, which behavior should be the default.

[pekam]

We keep the default functionality as entering grace period. Waiting for more feedback before potentially implementing this configuration.

[Legioth]

There are two different use cases that we might want to support:

1. Try to avoid triggering the grace period but still have it available as a fallback in case there's some situation that isn't anticipated by the application developer. In this case, actions such as showing a CollaborationAvatarGroup component would be guarded by a requestAccess check that would be explicitly configured to not trigger the grace period.
2. Don't use the grace period at all. In this case, it wouldn't be enough to limit requestAccess, but instead all Collaboration Engine features should have a global configuration to disable the grace period.