A group that someone is added to by way of membership in subgroup that’s added to that group can not be forked into by members of the subgroup

Summary

Imagine a user is added as a member of a subgroup. That subgroup is added as a member to a group. The user should be able to choose that group as a namespace when creating a fork.

Said differently: a group that someone is added to by way of membership in subgroup that’s added to that group can not be forked into by members of the subgroup (the target group simply does not appear in the list of Groups and subgroups that can be forked into).

Steps to reproduce

Complete these tasks as one user (who we will call Tan):

  1. Create a group abounding and create a subgroup abounding/bizarre
  2. Add a user (who we will call Uki) as a member of the abounding/bizarre subgroup with the Maintainer role
  3. Create a group gigantic
  4. Add the abounding/bizarre subgroup as a member of the gigantic group with the Maintainer role

Complete these tasks as Uki:

  1. Observe that you can view the gigantic group
  2. Browse to a project in the GitLab instance and click Fork
  3. Observe that you can choose abounding/bizarre in the list of Groups and subgroups you can fork into
  4. Observe that the gigantic group does not appear in the list of Groups and subgroups you can fork into

The user Uki can create a new project in the gigantic group. I created quick videos demonstrating the steps taken as Uki on gitlab.com and a self-managed instance running 13.11.3. See the Relevant logs and/or screenshots section of this issue for the videos.

Example Group, Subgroup and Project

The gigantic group that can't be chosen from the list of Groups and subgroups to fork into is: https://gitlab.com/213378-rbac-project-group. The abounding/bizarre subgroup that Uki is added as a member to is https://gitlab.com/213378-rbac-testing/rbac/isac-aligned/build-and-release-engineer. The https://gitlab.com/213378-rbac-testing/rbac/isac-aligned/build-and-release-engineer group is a member of https://gitlab.com/213378-rbac-project-group with the Maintainer role.

What is the current bug behavior?

The group that contains the subgroup that the user is directly added to does not appear in the list of Groups and subgroups that can be selected when forking a project.

What is the expected correct behavior?

The group that contains the subgroup that the user is directly added to should appear in the list of Groups and subgroups that can be selected when forking a project.

Relevant logs and/or screenshots

The gigantic group should appear here:

gigantic-not-shown-in-list-of-groups-subgroups

Here's a video showing this on gitlab.com:

reproducing-213378-gitlab-com

Here's a video showing the undesired behavior on 13.11.3:

repro-sm-13-11-3

Output of checks

This bug happens on GitLab.com and in a self-managed instance running 13.11.3.

Results of GitLab environment info

Expand for output related to GitLab environment info 
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

System information
System:		Ubuntu 18.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.7.2p137
Gem Version:	3.1.4
Bundler Version:2.1.4
Rake Version:	13.0.3
Redis Version:	6.0.12
Git Version:	2.31.1
Sidekiq Version:5.2.9
Go Version:	unknown

GitLab information
Version:	13.11.3-ee
Revision:	7fde0affe23
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.6
URL:		https://omg.brie.dev
HTTP Clone URL:	https://omg.brie.dev/some-group/some-project.git
SSH Clone URL:	git@omg.brie.dev:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	yes
Using Omniauth:	yes
Omniauth Providers: auth0

GitLab Shell
Version:	13.17.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell
Git:		/opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)


Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.17.0 ? ... OK (13.17.0)
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: ... Checking Reply by email ...


IMAP server credentials are correct? ... Checking REDACTED@REDACTED.REDACTED
yes
Init.d configured correctly? ... skipped
MailRoom running? ... skipped


Checking Reply by email ... Finished


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... Server: ldapmain
not verifying SSL hostname of LDAPS server 'REDACTED'
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
User output sanitized. Found 3 users of 100 limit.


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
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
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: ...
2/1 ... yes
4/2 ... yes
4/3 ... yes
5/4 ... yes
5/5 ... yes
6/6 ... yes
6/7 ... yes
1/8 ... yes
9/9 ... yes
5/10 ... yes
1/11 ... yes
5/12 ... yes
1/13 ... yes
13/14 ... yes
19/15 ... yes
20/16 ... yes
20/17 ... yes
20/18 ... yes
19/19 ... yes
21/20 ... yes
21/21 ... yes
21/22 ... yes
22/23 ... yes
22/24 ... yes
5/25 ... yes
1/26 ... yes
25/27 ... yes
26/28 ... yes
Redis version >= 5.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.31.0 ? ... yes (2.31.1)
Git user has default SSH configuration? ... yes
Active users: ... 4
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

Possible fixes

Edited by Brie Carranza