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):
- Create a group
abounding
and create a subgroupabounding/bizarre
- Add a user (who we will call Uki) as a member of the
abounding/bizarre
subgroup with the Maintainer role - Create a group
gigantic
- Add the
abounding/bizarre
subgroup as a member of thegigantic
group with the Maintainer role
Complete these tasks as Uki:
- Observe that you can view the
gigantic
group - Browse to a project in the GitLab instance and click Fork
- Observe that you can choose
abounding/bizarre
in the list of Groups and subgroups you can fork into - 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:
Here's a video showing this on gitlab.com
:
Here's a video showing the undesired behavior on 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