Non-admin users cannot fork projects to group with restricted visibility level
Summary
It is possible to restrict certain visibility levels (public
, internal
and private
) can be restricted for new groups and projects in the GitLab Admin area, see https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#restrict-visibility-levels. These restrictions only applies to non-admin users and not to admin users or admin mode.
When the visibility levels are restricted and a non-admin user wants to fork a project into a group (or namespace) with a restricted visibility level then this non-admin user is not able to do this. Please see the section "Steps to reproduce" to have a more tangible example.
Important note: Admin users are not facing this issue because these users are not affected by restricted visibility levels. Therefore, they will be able to select all groups (or namespaces) when forking a project.
Steps to reproduce
To reproduce the bug, you need two users:
- Admin user
- Non-Admin user that is a group member at level
owner
Steps to reproduce with the admin user:
- Sign in as the admin user
- Go to Admin Area => Settings => General => Section
Visibility and access control
: http://gdk.test:3000/admin/application_settings/general#js-visibility-settings - In the section
Restricted visibility levels
, checkPublic
as one of the restricted restricted visibility levels - Create a new group
bug-fork-internal-project-public-group
with the visibility levelpublic
: http://gdk.test:3000/groups/new - Add the non-admin user as a member with access level
owner
to the created groupbug-fork-internal-project-public-group
Steps to reproduce with the non-admin user:
- In a new private browser tab, sign in as a non-admin user (<= this is important)
- Go to your group overview: http://gdk.test:3000/dashboard/groups
- Create another group
bug-fork-internal-project-internal-group
with the visibility levelinternal
: http://gdk.test:3000/groups/new - Create a subproject
internal-project-to-be-forked
in the groupbug-fork-internal-project-internal-group
with the visibility levelinternal
- Go to the fork page of project
internal-project-to-be-forked
: http://gdk.test:3000/bug-fork-internal-project-internal-group/internal-project-to-be-forked/-/forks/new - In the field
Project URL
, try to select the groupbug-fork-internal-project-public-group
as the namespace - As shown in the screenshot below, it is not possible to select the public group that we created before
🤷
What is the current bug behavior?
In the field Project URL
, it is not possible to choose the group bug-fork-internal-project-public-group
as the namespace from the dropdown although it is a public group, see screenshot above. The reason is that the groups with a restricted visibility level are excluded from this dropdown.
Disclaimer: Of course, this might be expected behavior, but it feels strongly inconsistent because non-admin users can create new internal projects in public groups without a problem. Therefore, we are not sure if we consider this issue a bug or rather an enhancement of the existing functionality.
What is the expected correct behavior?
We expect that the restrictions of visibility levels do not affect the selection of namespaces (groups) when a project is forked. Of course, actual visibility level of the newly created project is affected by the restricted visibility levels.
This means, it should be possible to fork an internal project into a public group even when the visibility level public
is rectricted. Of course, the newly created project (after the fork) will have the visibility level internal
because the visibility level public
is restricted.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
➜ gitlab git:(master) be rake gitlab:env:info System information System: Proxy: no Current User: client-siemens Using RVM: no Ruby Version: 3.2.3 Gem Version: 3.5.11 Bundler Version:2.5.11 Rake Version: 13.0.6 Redis Version: 7.0.14 Sidekiq Version:7.1.6 Go Version: go1.22.3 darwin/arm64 GitLab information Version: 17.1.0-pre Revision: 68e85e2ec60 Directory: /Users/client-siemens/Development/gitlab-development-kit/gitlab DB Adapter: PostgreSQL DB Version: 14.9 URL: http://gdk.test:3000 HTTP Clone URL: http://gdk.test:3000/some-group/some-project.git SSH Clone URL: ssh://git@gdk.test:2222/some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: google_oauth2 GitLab Shell Version: 14.35.0 Repository storages: - default: unix:/Users/client-siemens/Development/gitlab-development-kit/praefect.socket GitLab Shell path: /Users/client-siemens/Development/gitlab-development-kit/gitlab-shell Gitaly - default Address: unix:/Users/client-siemens/Development/gitlab-development-kit/praefect.socket - default Version: 17.0.0-rc2-261-g1fb4c252c - default Git Version: 2.45.1
Results of GitLab application Check
Expand for output related to the GitLab application check
➜ gitlab git:(master) rake gitlab:check SANITIZE=true Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 14.35.0 ? ... OK (14.35.0) Running /Users/client-siemens/Development/gitlab-development-kit/gitlab-shell/bin/check {"content_length_bytes":90,"correlation_id":"01HZF59N7CDH361VDMH73VH44D","duration_ms":445,"level":"info","method":"GET","msg":"Finished HTTP request","status":200,"time":"2024-06-03T13:40:53Z","url":"http://gdk.test:3000/api/v4/internal/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: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes Tables are truncated? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... no Try fixing it: sudo chmod 700 /Users/client-siemens/Development/gitlab-development-kit/gitlab/public/uploads For more information see: doc/install/installation.md in section "GitLab" Please fix the error above and rerun the checks. Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet) Systemd unit files or init script exist? ... no Try fixing it: Install the Service For more information see: doc/install/installation.md in section "Install the Service" Please fix the error above and rerun the checks. Systemd unit files or init script up-to-date? ... can't check because of previous errors Projects have namespace: ... 22/1 ... yes 24/2 ... yes 24/3 ... yes 27/4 ... yes 29/5 ... yes 31/6 ... yes 33/7 ... yes 35/8 ... yes 58/9 ... yes 10/10 ... yes 49/11 ... yes 12/12 ... yes 13/13 ... yes 43/14 ... yes 9/15 ... yes 56/16 ... yes 6/17 ... yes 17/18 ... yes 1/19 ... yes 1/20 ... yes 1/21 ... yes 1/22 ... yes 1/23 ... yes 1/24 ... yes 29/25 ... yes 104/26 ... yes 106/27 ... yes 109/28 ... yes 113/29 ... yes 115/30 ... yes 117/31 ... yes 119/32 ... yes 1/33 ... yes 125/34 ... yes 128/35 ... yes 127/36 ... yes Redis version >= 6.2.14? ... yes Ruby version >= 3.0.6 ? ... yes (3.2.3) Git user has default SSH configuration? ... no Try fixing it: mkdir ~/gitlab-check-backup-1717422068 sudo mv /Users/client-siemens/.ssh/config ~/gitlab-check-backup-1717422068 sudo mv /Users/client-siemens/.ssh/gitpod ~/gitlab-check-backup-1717422068 sudo mv /Users/client-siemens/.ssh/id_ed25519 ~/gitlab-check-backup-1717422068 sudo mv /Users/client-siemens/.ssh/id_ed25519.pub ~/gitlab-check-backup-1717422068 sudo mv /Users/client-siemens/.ssh/known_hosts.old ~/gitlab-check-backup-1717422068 For more information see: doc/user/ssh.md#overriding-ssh-settings-on-the-gitlab-server Please fix the error above and rerun the checks. Active users: ... 68 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-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled) All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
When forking a project, the field Project URL
shows all available namespaces that can be used for the new project. For the list of available namespaces, we propose to disregard the restricted visibility levels. In other words, the restricted visibility levels should not determine namespaces are available or not.