Creating a new project does not select the proper visibility when changing the group to a restricted visibility group

Summary

When creating a new project, then changing the group to a group with restricted visibility lower than the currently selected project visibility, the project visibility radio buttons maintain selection of the, now invalid, visibility options.

Steps to reproduce

1. Create a group with restricted visibility, say Private.
2. Go to Create a new Project
3. Select a visibility above the visibility of the group from Step#1, in this case say Public
4. Select the Group created in Step#1
5. Observe the previously selected visibility selected, but greyed out
6. Fill in the project name and create the project
7. Note that the visibility is within the valid visibility denoted by the group, however that was never selected in project creation

Example Project

Not applicable here as it is for project creation.

What is the current bug behavior?

The visibility selection doesn't reflect the actual visibility that will be used on creation.

This could lead to confusion when creating new projects.

What is the expected correct behavior?

The visibility radios would auto check to the next highest, valid, visibility level to reflect what the project would actually be created using.

e.x.

• Group is Internal
• Project starts as Public
• When selecting the Internal group, the radios select Internal for the project visibility

This will show the user immediately what visibility the project will actually be created using, allowing them to adjust their expectations more easily.

Relevant logs and/or screenshots

Project creation:

Project Visibility Result:

Output of checks

Results of GitLab environment info

GitLab environment info (Tested System 1 14.9.2-ee)

System information
System:         Ubuntu 18.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.7.5p203
Gem Version:    3.1.4
Bundler Version:2.2.33
Rake Version:   13.0.6
Redis Version:  6.2.6
Sidekiq Version:6.4.0
Go Version:     unknown

GitLab information
Version:        14.9.2-ee
Revision:       3034418fb31
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     12.7
URL:            ********
HTTP Clone URL: ********
SSH Clone URL:  ********
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

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

GitLab environment info (Tested System 2 15.2.2-ee)

System information
System:
Proxy:          NO_PROXY: ********
                ftp_proxy: ********
                FTP_PROXY: ********
                HTTPS_PROXY: ********
                no_proxy: ********
                HTTP_PROXY: ********
                https_proxy: ********
                http_proxy: ********
Current User:   git
Using RVM:      no
Ruby Version:   2.7.5p203
Gem Version:    3.1.4
Bundler Version:2.3.15
Rake Version:   13.0.6
Redis Version:  6.2.7
Sidekiq Version:6.4.0
Go Version:     unknown

GitLab information
Version:        15.2.2-ee
Revision:       4420a6308aa
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     12.10
URL:            ********
HTTP Clone URL: ********
SSH Clone URL:  ********
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

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

Results of GitLab application Check

Not Applicable

Possible fixes

The radio buttons should simply be altered to auto-select the next highest visibility level allowed by the selected group.