GitLab

Created by: Liukke

Summary: A user with master access to a project attempts to change the default branch, but it fails with the "Limit reached Your own projects limit is 10! Please contact administrator to increase it" error and was only corrected by changing the limit on a different user.

Steps to reproduce:

1. Create a new project group on user A
2. Add enough projects to the group to reach user A's limit
3. Set user B with master access to one of these projects
4. User B attempts to change the default branch for this project and will get the error "Limit reached Your own projects limit is 10! Please contact administrator to increase it"
5. Increase user B's project limit
6. Attempt to change the default branch for the same project as user B again will fail with the same error
7. Increase user A's project limit
8. Attempt to change the default branch for the same project as user B will now succeed

Expected behavior: I am expecting a change to a default branch for a project to succeed regardless of whether a user's max project limit has been reached or not since changing this setting is not creating a new project. However, it appears that the limit is preventing settings for the project from being saved at all.

Observed behavior: Naturally, we went to the user B's project limit setting and increased it thinking this would fix the problem. We still got the same error. We played around with this for a bit and then realized the project was actually created by a different user, user A, under a project group that user A had created. We decided to change user A's project limit. Then changes to the project settings by user B saved properly.

Output of checks: Running gitlab 5.3 commit # e1c473c1 Application check

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.4.0 ? ... OK (1.4.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... yes
post-receive hooks in repos are links: ... 
<redacted all are ok>

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have satellites? ... 
<redacted all checkout to yes>
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.7.11)

Checking GitLab ... Finished

Environment check:

System information
System:         RedHatEnterpriseServer 6.4
Current User:   git
Using RVM:      no
Ruby Version:   1.9.3p392
Gem Version:    1.8.23
Bundler Version:1.3.4
Rake Version:   10.0.4

GitLab information
Version:        5.3.0
Revision:       e1c473c
Directory:      /home/git/gitlab
DB Adapter:     postgresql
URL:            <redacted>
HTTP Clone URL: http://<redacted>/some-project.git
SSH Clone URL:  git@<redacted>:some-project.git
Using LDAP:     yes
Using Omniauth: no

GitLab Shell
Version:        1.4.0
Repositories:   /home/git/repositories/
Hooks:          /home/git/gitlab-shell/hooks/
Git:            /usr/bin/git

Possible fixes: It appears the project limit of user A who owns a project is what is being checked when when user B attempts to change the project. Also, it shouldn't matter if the project limit has been reached for changing existing project settings.