Design an onboarding process

[lorenzleutgeb]

We currently have a handful of onboarding scenarios:

Registration:

1. User visits website
2. Decides she wants to use our service
3. Navigates to a register form
4. Provides all necessary data, including:
   • E-mail address (mandatory)
   • Nickname (mandatory)
   • Password (mandatory)
   • Real name (optional)

Challenge invitation:

1. Company has contact information of a user, and provides us with
   • E-Mail (mandatory)
   • Nickname (optional, let's leave this open)
   • Real name (optional)
2. We invite the user by sending an e-mail. The e-mail contains known contact information where possible. E.g. "Hello Max Mustermann!" if we know the real name, and "Hello!" if we don't know the name.
3. The user arrives at our page via the personalized URL.
4. We encourage the user to complete registration by setting (or overriding) all personal data, except the e-mail address.

At all times, we want to have accurate and consistent data in our database, which is a pain right now, as we'd probably see NULLs for nickname and password. Therefore I propose to reconsider the concept of a "User" as such, and define a more decoupled way of storing user data.

For example, we could represent an object that associates with forms of authentication (tokens, passwords, 2FA secrets) and identifiers (real name, nickname, e-mail address), and only establish a relation once we have that information.

[lorenzleutgeb]

This got even trickier with invitations:

class Invitation {
    @Id
    private String token;

    @NotNull
    private String email;

    @ManyToOne(optional = false)
    private Challenge challenge;
}

Invitations are lacking fields to store the first name and last name of a user, so the design in the first post cannot be modeled.

We once decided to not create a User right after invitation, but this would be beneficial:

• The token in Invitation could be a regular access token that relates to the User.
• We can just use User.(first|last)Name right away.
• When resolving a Nickname (for example using GithubService), we can do that right after the invitation e-mail was sent out. This way we do not delay the initial request when the user navigates to the token URL.
• We can still find out whether a User is "active" by checking for logins (User.lastLogin) and collect garbage.