Related to options for restriction of team creation, we have a design here for the Mattermost landing page used to create new teams when multiple sign-in options are offered.
When more than one authentication option is offered we have this team creation page:
Which will lead to a page to fill out a team name, and then auth with chosen method, where “Create team with…” button is disabled until a valid team name is selected:
The creation of teams with email sign-up would happen as it does in the default experience without SSO options.
Looks good, I like the aesthetics of it. Before I continue my implementation I have a question about functionality:
Once the user clicks ‘Create team with GitLab Account’ they will be redirected to GitLab to login/give Mattermost access. They will then be redirected to Mattermost. When it’s a user joining an existing team we ask the user here what username they want (with the field auto-populated from their GitLab account). For creating the user during SSO team creation we can either do the same or just try their username automatically (and append a number if the username is taken). Which do you think is better?
I personally think it would be better to automatically use the username from GitLab and then if the user doesn’t like it they can change it once in the team. It’s one less step for the user in the sign-up flow. If this is how we want to do it, would we want to change for signing up users for existing teams as well (it would make the code simpler)?
@jwilander, agree on using the default username in SSO accounts for creating the new user accounts in Mattermost–and they can always change it.
However, there may also be a case where a valid username in GitLab or Google isn’t valid in Mattermost, so in that case I propose we add logic to:
Automatically omit invalid characters from SSO username
Add a 1 if we hit a duplicate of an existing name (don’t think it’s worth the work to enumerate right now)
For Google accounts (and other SSO to come), propose we use the part of the user’s email address ahead of the @. In the typical case where people are coming from the same @domain.com it should be okay, and in the corner case where it’s a bunch of random email accounts, the odds of collision are still pretty low, you’d need "jenlee@gmail.com" to hit "jenlee@hotmail.com", which is going to be rare, and we’ll handle it with 2) above anyway.
There may be corner cases coming with LDAP usernames, and we’ll handle those as we hit them.
