Send email to EE admins on reaching active user count threshold
What does this MR do?
This merge request implements a feature for EE instances only.
We already have threshold values defined in the License
model so now we need to hook into several places where our goal is:
- Validate if an EE instance is approaching the active user count threshold.
- If yes, then we want to send email to all EE admins with warning.
- If no, do nothing.
The most complicated task was to hook into all places where users count changes. Example of these places:
users/create_service.rb
users/destroy_service.rb
As the first approach, I decided to hook into the mentioned files but then I realized that there are can be more places to cover. Instead of that, I hook into a single class HistoricalData
which we use to track active user count. This class is used by our worker HistoricalDataWorker
. I think this is the best place to cover all requirements.
Next (current) Iteration
With help from @mkaeppler we identified that HistoricalDataWorker
is not a good place for the implementation because it would be not obvious to search this thing there. Instead, I implemented the new worker ActiveUserCountThreshold
which validates if the current active user count reached the threshold and if so, it sends an email. This worker runs once per day at midnight.
Closes https://gitlab.com/gitlab-org/gitlab/-/issues/230608.
Screenshots
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