<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=331620) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=331620) </details> <!--IssueSummary end--> In this MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62306, we changed the behaviour of the visibility level. It was to resolve the issue of a disabled radio option being selected :scream: | :bug: Before | :white_check_mark: After (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62306) | | ------ | ------ | |  |  | ## Improvement 1 Let's improve this UX as remembering a previously selected visibility level is a nice convenience for our users 👍 Whereby if the previously selected visibility level is allowed, it will not reset. And it will only reset (to the default "Private") if the previously selected visibility level is a disabled option. --- Optionally, we could also set it to `null` (no option selected) when namespace is changed :thinking: ## Improvement 2 In this MR > https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62340, when a `restrictedVisibilityLevel` is selected, it will reset to `null`. Let's make the UX smarter. A. Initialize it to the visibility level of the project; unless it's restricted, in which case default to the highest visibility level (Private > Internal > Public) B. When namespace changes, it remembers the previous selected visibility level taking into account of the `restrictedVisibilityLevel`