Isolate silver/gold private groups from the rest of GitLab.com when adding group members
Problem
When inviting users into a private group, it's possible to see every user on GitLab.com which means that Enterprises could accidentally add the wrong user to their private organisation's group. Adding a random user by accident exposes their company data and is a potential security breach. Enterprise organisations might require an incident report to be written up as a result, creating unnecessary work for their administrators.
Additionally, even if they add the correct userid, that userid may be attached to an account that does not have the users work email address attached to it, but rather, their personal email, and the Group Owner would have no way of knowing if the user has hidden their email address from public view. Lastly, if adding inappropriate accounts with non-work emails happens frequently, once Group Managed Accounts is enabled, all of those users would have to be updated to comply with the group's access settings, potentially destroying any user mapping and role/permissions settings.
Proposal
- When inviting users into a private, silver/gold group or subgroup (or editing their roles and expiration date), users that are not whitelisted by the Group Admin at the parent group level should not be included in the available list of users via autocomplete.
- This means that the Group Owner/Admin will be able to define at the top level who has access to that group, and mitigate any potential risk of adding the wrong person or an non-compliant account.