Group members domain whitelist should allow multiple domains

Problem to solve

The domains whitelisting feature was implemented after one of our employees requested it - however we've been unable to enable / use this feature as we often need to bring users who do not have a corporate e-mail account at our company's domain (e.g. clients) into our GitLab projects, and so with the current behaviour it's not possible to enable the domain whitelist because we are unable to add more than a single domain to the whitelist.

Intended users

Initially GitLab admins will use this feature, to allow them to specify a list of domains from which users can be added from - the users actual vertical (e.g. Product Manager, Developer) isn't clear to me at this point.

Further details

This minor change makes the domain whitelisting feature more flexible and therefore hopefully more useful to users who work collaboratively with external stakeholders. It also promotes improved security/privacy in that it could help more users lock down their GitLab organisations and prevent them from accidentally granting access to people who should not be given access.

Proposal

It was proposed in #7297 (comment 174792745) that the values in the input could simply be separated by a delimiter (e.g. ; or ,). I'm not sure if you already have a UI pattern for this sort of multi-input so if that's inline with the existing pattern if one exists then fine.

First iteration

A comma separated list of email domains

Second iteration

Implement the GitLab UI "Token Selector" component: #220567 (closed)

Permissions and Security

The permissions required to edit the domain whitelist field should not be changed as part of this proposal.

Documentation

I couldn't find any docs for the existing domain whitelist configuration (but I'm not sure if I was looking in the right place), so that should probably be added and expanded upon for this change.

Testing

TBD

What does success look like, and how can we measure that?

What is the type of buyer?

This is an additional security feature, so should probably belong to Gold/Ultimate.

User reports/requests

Issue readiness

Product: issue description is accurate with an acceptable proposal for an MVC
Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated

Edited Jun 05, 2020 by Peter Hegman