### Problem to solve Especially in GitLab.com it is not already clear that seeing visibility to Internal includes visibility for those outside of your group. ### Intended users Project and Group Administrators ### Example scenarios * An administrator has a group that they are paying for on GitLab.com. When that customer wants to adjust the visibility of a Private project to Internal they would naturally assume that is Internal to their group - but in this case it is not. * A GitLab team member has created a group with customer sensitive information. They'd like to share it with all other GitLab team members so set that project to internal but it has the effect of immediately leaking all information to the public (since we allow public signup on GitLab.com). * A project administrator on a customer instance that allows for public comments on their issues in some part of the instance changes a sensitive project from Public to Internal assuming that means internal to team members. That project administrator might not even be aware that there are public domain (non-employees) using their instance and has then leaked private information to those public users. ### Further details If I navigate to the settings page for a Project I own I'm presented with the following under visibility options.  It's not immediately clear that when I choose Internal it is providing access to anyone using the entire instance.  ### Proposal Present a modal when changing to `Internal` or `Public` that states: For Internal: > **Change visibility to Internal?** > > Setting project visibility to `Internal` will allow ALL logged in users of the XXX GitLab instance, regardless of group, visibility to your project. > > Cancel | Confirm For Public: > **Change visibility to Public?** > > Setting project visibility to `Public` will allow anyone with public access to the XXX GitLab instance, visibility to your project. > > Cancel | Confirm ### Design:  On_Confirmation: The alert will disappear and the user can continue adjusting their settings as desired. On_Cancel: the alert will disappear and the visibility will revert to what it originally was ### Permissions and Security The security implications to the potential on-warned changes users can make are significant as outlined above. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references