Skip to content

The `New Subgroup` button is enabled even if a user can not create new groups and leads to a 404 error page

Summary

The New Subgroup button is enabled even if a user can not create new groups and leads to a 404 error page.

Steps to reproduce

  1. Create a new user.
  2. Add the new user to a group (e.g. test-group) as owner.
  3. Remove the Can create group right in the Admin-Panel > Access dialog.
  4. Navigate to the subgroup dialog of the group the user is owner of (e.g. https://gitlab.com/groups/test-group/subgroups).
  5. Press the New Subgroup button.

What is the current bug behavior?

The New Subgroup button is visible, enabled and leads to a 404 - Page not found error.

What is the expected correct behavior?

The New Subgroup button should not be visible at all.

Relevant logs and/or screenshots

image

Button is active even without required access rights. Pressing the button leads to 404.

Output of checks

Issue would also appear on gitlab.com.

Results of GitLab environment info

System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   2.3.3p222
Gem Version:    2.6.6
Bundler Version:1.13.7
Rake Version:   10.5.0
Redis Version:  3.2.5
Git Version:    2.10.2
Sidekiq Version:4.2.7

GitLab information
Version:        9.0.0
Revision:       cf020e6
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
Using LDAP:     yes
Using Omniauth: yes
Omniauth Providers: saml

GitLab Shell
Version:        5.0.0
Repository storage paths:
- default:      /data/gitlab/git/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:            /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Checking GitLab Shell ...

GitLab Shell version >= 5.0.0 ? ... OK (5.0.0)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
8/1 ... ok
7/3 ... repository is empty
12/4 ... repository is empty
17/5 ... repository is empty
7/6 ... ok
9/7 ... repository is empty
36/8 ... ok
42/9 ... repository is empty
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

Reply by email is disabled in config/gitlab.yml

Checking Reply by email ... Finished

Checking LDAP ...

Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)

[...]

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
projects have namespace: ...
8/1 ... yes
7/3 ... yes
12/4 ... yes
17/5 ... yes
7/6 ... yes
9/7 ... yes
36/8 ... yes
42/9 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.3)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.10.2)
Active users: 43

Checking GitLab ... Finished

Possible fixes

The file app/views/groups/subgroups.html.haml uses - if can? current_user, :admin_group, @group as check if a user can create subgroups. However, this does not check if a user is able to create a group in the first place as it's done on group level with - if current_user.can_create_group?.