Owner Permissions Not Carried Down to Subgroups

Summary

After creation of subgroups, the owners of the top group show up as owners but are not allow to create new projects in the subgroups till added as owners in the subgroup. All other permissions seem to be carried down, just not owner.

Steps to reproduce

1. As an admin create a group and create a new subgroup
2. Assign an Owner to the top level group
3. Login as the Owner and try and create a subgroup or new project under the subgroup

What is the current bug behavior?

• A 404 pages is shown when trying to create a subgroup
• Not able to create a project in the subgroup

Results of GitLab environment info

System information
System:		Ubuntu 16.04
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
URL:		https://gitlab.<company-name-removed>.com
HTTP Clone URL:	https://gitlab.<company-name-removed>.com/some-group/some-project.git
SSH Clone URL:	git@gitlab.<company-name-removed>.com:some-group/some-project.git
Using LDAP:	yes
Using Omniauth:	no

GitLab Shell
Version:	5.0.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/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: ... 
4/1 ... ok
14/3 ... repository is empty
5/4 ... ok
40/5 ... repository is empty
4/6 ... repository is empty
15/7 ... ok
15/8 ... ok
13/9 ... ok
5/10 ... ok
21/11 ... ok
5/12 ... ok
22/13 ... ok
22/14 ... ok
21/15 ... ok
41/16 ... repository is empty
41/17 ... repository is empty
41/18 ... ok
41/19 ... ok
41/20 ... ok
41/21 ... ok
40/22 ... repository is empty
19/24 ... ok
13/25 ... ok
36/26 ... repository is empty
37/27 ... ok
39/28 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: The environment variable HTTP_PROXY is discouraged.  Use http_proxy.
The environment variable HTTP_PROXY is discouraged.  Use http_proxy.
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)

    ... Removed for security ...

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: ... 
4/1 ... yes
14/3 ... yes
5/4 ... yes
40/5 ... yes
4/6 ... yes
15/7 ... yes
15/8 ... yes
13/9 ... yes
5/10 ... yes
21/11 ... yes
5/12 ... yes
22/13 ... yes
22/14 ... yes
21/15 ... yes
41/16 ... yes
41/17 ... yes
41/18 ... yes
41/19 ... yes
41/20 ... yes
41/21 ... yes
40/22 ... yes
19/24 ... yes
13/25 ... yes
36/26 ... yes
37/27 ... yes
39/28 ... 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: 23

Checking GitLab ... Finished

Possible fixes

TBD

/cc @dzaporozhets

added ~480950 ~12980 subgroups user management labels

@bellhop Thanks for raising an issue about this

We are experiencing similar behaviour (tested in 9.0.0, 9.0.1, 9.0.2) - except that we see the 404 when attempting to create the first sub-group as the group 'Owner'.

added Next Patch Release regression labels

changed milestone to %9.1

I have a similar issue on gitlab.com but using the Master permissions. I have Master permissions in the parent group, and in the subgroup I'm shown as master as well, but I am not able to create projects in this subgroup.

I will take a look

assigned to @dzaporozhets

I can reproduce in on 9.0.2 but not on latest master. Seems to be fixed but I need to find commit

OK looks like it was fixed by https://gitlab.com/gitlab-org/gitlab-ce/commit/2f9d50b72fedf09900289e6a0bcf59433d0c05f5. All I need to do is add some extra test to make sure bug does not appear again

mentioned in merge request !10486 (merged)

I created https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10486 to ensure existing behavior:

• group owner can create subgroup
• group master can create projects in subgroups

Thank you guys and gals for all of your hard work on GitLab!!!

closed

Master has correct behavior and tests now. I am closing the issue

mentioned in issue gitlab-com/support-forum#1703 (closed)

mentioned in issue #30697 (closed)

First of all let me thank you for the subgroup feature! It is really helpful.

However, I am still experiencing this bug in the latest community edition release (9.1.1). When creating a new project, group members (with master or owner permissions) of a parent group do not see the subgroups in the search form (cannot select it in the project path).

mentioned in issue #31445 (moved)