:tools: with :heart: at Siemens ### Summary 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 creating new groups and projects and not existing ones. When the visibility levels are restricted and a non-admin user visits the settings page of this group then the user might see: 1. No visibility level radio buttons at all (when the group contains a public project) 2. Incorrectly checked visibility level radio buttons (radio button `Private` is pre-checked although it is a public group) This is misleading and confusing for the user, see screenshot below. We need to refine the setting page view for non-admin users.  ### Steps to reproduce To reproduce the bug, you need two users: 1. Admin user 2. Non-Admin user that is a group member at level `owner` #### Steps to reproduce with the admin user: 1. Sign in as the admin user 2. Go to Admin Area => Settings => General => Section `Visibility and access control`: http://gdk.test:3000/admin/application_settings/general#js-visibility-settings 3. In the section `Restricted visibility levels`, check `Public` as one of the restricted restricted visibility levels 4. Create a new group `test-public-group-with-public-project` with the visibility level `public`: http://gdk.test:3000/groups/new 5. Add the non-admin user as group member with access level `owner` 6. Go to the general settings page of newly created group and look at the section `Visibility level`; you will see three radio buttons :thumbsup: 7. Do not close the browser tab and keep it open  #### Steps to reproduce with the non-admin user 1. In a new private browser tab, sign in as a non-admin user (<= this is important) 2. Go to the general settings page of newly created group (the non-admin user will have access because we have added this user as a group member) 3. Look at the section `Visibility level`; you will see that the visibility level radio button `private` is checked, see screenshot below <= this is not correct because the group actually has the visibility level `public` :boom: 4. Optional: When you create a public project within this group and visits the group settings with the non-admin user again then you will not see any radio buttons at all, see [screenschot _above_](/uploads/b08e82c443d721166cab669e9738318d/image.png)  ### Example Project ### What is the current *bug* behavior? The visibility section in the general group settings is misleading and confusing for non-admin users. In [the example screenshot shown before](/uploads/9a248e747b6891fb7fb98fbc1f8ddec8/image.png) non-admin users see that the radio button `Private` is checked and are confused because the group is actually public. Furthermore, when only one visibility level is restricted then there is no text hint letting the user know that a visibility level is restricted. The MR !149429 wants to address this missing text hint. ### What is the expected *correct* behavior? At least, we should ensure that the radio button `Private` is not checked when the group is actually public. We can achieve this by showing a **disabled** visibility level radio button `Public`. Furthermore, we should add a hint that points out that certain visibility levels are restricted for non-admin users. Currently, this text hint (i.e. alert) is only shown when multiple or all visibility levels are restricted, see https://gitlab.com/gitlab-community/gitlab/-/blob/b3b514f76f08dba4b9054dcbc694505704285571/app/views/shared/_visibility_radios.html.haml#L13. ### Relevant logs and/or screenshots ### Output of checks #### Results of GitLab environment info I am able to reproduce the problem on clean gdk instance. <details><summary>Expand for output related to the GitLab environment info</summary> ```text System information System: Proxy: no Current User: client-siemens Using RVM: no Ruby Version: 3.2.3 Gem Version: 3.5.8 Bundler Version:2.5.8 Rake Version: 13.0.6 Redis Version: 7.0.14 Sidekiq Version:7.1.6 Go Version: go1.21.7 darwin/arm64 GitLab information Version: 16.11.0-pre Revision: b75637a9d76 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.34.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: 16.10.0-rc1-157-g6abde2303 - default Git Version: 2.43.2 ``` </details> #### Results of GitLab application Check I am able to reproduce the problem on clean gdk instance. <details> <summary>Expand for output related to the GitLab application check</summary> <pre> ➜ gitlab git:(master) bundle exec rake gitlab:check Checking GitLab subtasks ... Checking GitLab Shell ... GitLab Shell: ... GitLab Shell version >= 14.34.0 ? ... OK (14.34.0) Running /Users/client-siemens/Development/gitlab-development-kit/gitlab-shell/bin/check {"content_length_bytes":91,"correlation_id":"01HV93M48V6VJ9ZQCB463ZSBD1","duration_ms":257,"level":"info","method":"GET","msg":"Finished HTTP request","status":200,"time":"2024-04-12T12:13:24Z","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: ... Toolbox / Gitlab Smoke Tests ... yes Gitlab Org / Gitlab Test ... yes Gitlab Org / Gitlab Shell ... yes Gnuwget / Wget2 ... yes Commit451 / Lab Coat ... yes Jashkenas / Underscore ... yes Flightjs / Flight ... yes Twitter / Typeahead.Js ... yes I User0 / Typeahead.Js ... yes Tara Carter / Flight ... yes I User0 / Flight ... yes Elanor Stamm / Typeahead.Js ... yes Eusebio Zulauf / Typeahead.Js ... yes I User0 / Wget2 ... yes Barbar Schoen / Wget2 ... yes I User1 / Flight ... yes Gudrun Hamill / Typeahead.Js ... yes Maryalice Denesik / Wget2 ... yes Administrator / Test Space Unauthenticated Web ... yes Administrator / Test Space Unauthenticated Web 2 ... yes Administrator / Test Space Unauthenticated Web 3 ... yes Administrator / Test Space Unauthenticated Web 4 ... yes Administrator / Test Space Unauthenticated Web Public 5 ... yes Administrator / Test Space Unauthenticated Web Public 6 ... yes Commit451 / Lab Coat 2 ... yes test-public-group-with-public-project / test-public-project-in-public-group ... yes test-public-group-with-public-project / test-subgroup-public / Test Project Public ... 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-1712924018 sudo mv /Users/client-siemens/.ssh/config ~/gitlab-check-backup-1712924018 sudo mv /Users/client-siemens/.ssh/gitpod ~/gitlab-check-backup-1712924018 sudo mv /Users/client-siemens/.ssh/id_ed25519 ~/gitlab-check-backup-1712924018 sudo mv /Users/client-siemens/.ssh/id_ed25519.pub ~/gitlab-check-backup-1712924018 sudo mv /Users/client-siemens/.ssh/known_hosts.old ~/gitlab-check-backup-1712924018 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 </pre> </details> ### Possible fixes Show all visibility level (radio buttons) and disable them when the visibility level is not allowed. Additionally, [use a popover](https://design.gitlab.com/usability/settings-management#settings-inheritance) to let non-admin users know why the visibility level is disallowed. See also https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149427.