Users created after User Cap limit is reached should be placed in blocked_pending_approval status
What does this MR do?
Context
#211390 (closed) introduced the User Cap setting which defines the max amount of billable users there can be in the instance. After that maximum number is reached, the instance admin has to review and approve any new user by navigating to Admin Area > Overview > Users > Pending Approval tab.
Users that register after the cap has been exceeded see this message when their account is created:
In case the admin wishes to re-enable open registration, they will need to increase the User Cap or set it to nothing (no limit).
Current approach
Use a before_create hook in the EE::User model. This hook will set the user's state to blocked_pending_approval if the User Cap has been exceeded. Any new user added via the registration form or the admin area will be created in blocked_pending_approval state.
| Problems | Benefits |
|---|---|
License#current_active_users_count times out in GL.com so this presents a performance concern for big self-managed instances. |
Real time count of billable users helps to use the limit accurately. |
In case of a timeout in the count, the user creation would fail because of the before_create hook. |
Users registering themselves would not be logged in automatically and would see a clear message about the need to get approval from the administrator. |
| Batch counts can't be called from inside the callback |
Related issue
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
- [-] Changelog entry
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
-
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec - [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team