User Caps Should Not Restrict New Guest Users
Note
This issue is code complete and behind a feature flag. Once blocking work is complete, we can proceed with the rollout and then close this issue.
Context
User caps helps GitLab Admins better control billable seats. Per the documentation:
When the number of billable users reaches the user cap, any user who is added or requests access must be approved by an administrator before they can start using their account.
Unfortunately, users that are not billable (e.g., Free Guest Users on Ultimate) are counted towards the user cap, limiting the usefulness of the feature. (not a problem per this note #361563 (comment 1709358681)).
Rather the problem is: once the user cap is reached, even users that are not billable (e.g., Free Guest Users on Ultimate) are marked pending approval when they are added to the instance
This issue is part of our Epic - Enhance User Caps (SM and SaaS) to better handl... (&8108)
Proposal
- When users are invited to an instance with a role that wouldn't be billable (e.g., Guest on an Ultimate instance), the user cap should not apply to that user's sign up. (Scope of this issue)
Not in scope
- If a change would turn a non-billable user into a billable user (e.g., a Free Guest user is added as higher access role on a project) then user caps should be checked. If the transition from Free Guest user to a paid seat would make the number of users exceed the user cap then it must require Admin approval. --> being handled here &12141
- [update 2023-07-11 per #361563 (comment 947779110)\\\] This check needs to be performed, and reviews/approvals needed, also when a Group is invited to a project/sub-group/etc. that would cause billable users to exceed the set user cap.
Related issues:
- notifying admin when guest moves into a paid seat after user has been approved
- controls for who can change guest permissions
- not allowing guests to move themselves into a paid seat
Old description
Summary
As the admin of a self-hosted ultimate instance, I add users to the platform via the api using a sync. These users need to stay in a "guest" status unless approved. Therefore I set the user cap to 1 with the expectation of being notified when users move into a status that would take up a license seat. Unfortunately I receive a notification any time ANY user is added my any means. This means that I am getting notified when my user sync process runs and adds any users to the system using the API or also when a user is added manually.To get more information, I approved one of these users and verified that they indeed did NOT take up a seat and remained in the guest" status.I verified this behavior on a fresh install of EE (no license installed).
Steps to reproduce
- spin up a new instance of gitlab with an Ultimate subscription
- set user cap to 1
- add guest users to the platform
- get notification
What is the current bug behavior?
user cap including guest users when determining if admin needs to approve
What is the expected correct behavior?
Guest users should not be included in this process. Users should be able to be added without issue and admin only notified to approve when they will be moved into a license seat
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
root@4cf57061ed10:/# gitlab-rake gitlab:env:info System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.5p203 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.6 Redis Version: 6.2.6 Sidekiq Version:6.4.0 Go Version: unknown GitLab information Version: 14.8.2-ee Revision: 20a7fdf52c9 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.4 URL: https://spork-plus.fusion.navy.mil HTTP Clone URL: https://spork-plus.fusion.navy.mil/some-group/some-project.git SSH Clone URL: git@spork-plus.fusion.navy.mil:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: cas3 GitLab Shell Version: 13.23.2 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Results of GitLab application Check
Expand for output related to the GitLab application check
root@4cf57061ed10:/# gitlab-rake gitlab:check SANITIZE=true Checking GitLab subtasks ... Checking GitLab Shell ... GitLab Shell: ... GitLab Shell version \\\\\\\>= 13.23.2 ? ... OK (13.23.2) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Gitaly ... Gitaly: ... default ... OK Checking Gitaly ... Finished Checking Sidekiq ... Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1 Checking Sidekiq ... Finished Checking Incoming Email ... Incoming Email: ... Reply by email is disabled in config/gitlab.yml Checking Incoming Email ... Finished Checking LDAP ... LDAP: ... LDAP is disabled in config/gitlab.yml Checking LDAP ... Finished Checking GitLab App ... Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 2/1 ... yes 115600/2 ... yes 13814/3 ... yes 115600/4 ... yes 116510/5 ... yes 116580/6 ... yes 116579/7 ... yes 58861/8 ... yes 116664/9 ... yes 123450/12 ... yes 123450/14 ... yes 123450/15 ... yes 123449/16 ... yes 123449/18 ... yes Redis version \\\\\\\>= 5.0.0? ... yes Ruby version \\\\\\\>= 2.7.2 ? ... yes (2.7.5) Git user has default SSH configuration? ... yes Active users: ... 119733 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled) Checking GitLab App ... Finished Checking GitLab subtasks ... Finished