License isn't consumed immediately when new Admin account logs in via LDAP
Summary
Customer reported that logging in via a new account that's a member of the LDAP admin group doesn't consume a license seat immediately. They have to create a group or project, and then the count updates.
Steps to reproduce
Chart gitlab-3.0.4 , Gitlab App 12.7.6
- Deploy Gitlab using helm charts
- Configure an LDAP group for accounts that will have admin rights in GitLab
- Login as "root" user and change the admin settings "Settings -> General -> Account and limit -> (Check) Newly registered users will by default be external"
- Log out; log in as a user in the administrators LDAP group.
- Wait for LDAP to sync (or wait until you can see the Admin panel)
- Once the admin panel shows up, you can see that the user license seat is 0. You can also hit the GET /license API or run the rails console commands indicated in Gitlab docs, and still see maximum_user_count report 0 for the user
- Create a group or project as the user, the maximum_user_count update to 1.
Example Project
(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)
(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)
What is the current bug behavior?
maximum_user_count = 0 until certain activity is performed by the user.
What is the expected correct behavior?
maximum_user_count = 1 once the user is created
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Chart gitlab-3.0.4 , Gitlab App 12.7.6
Results of GitLab application Check
Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
Edited by Ben Prescott_