Remove required fields from user

[hifabienne]

As an administrator, I want to be able to create users with only a username, making other fields like email, first name, and last name optional, so that I can accommodate diverse user onboarding scenarios and streamline the creation process.

Description

Currently, the user creation process requires several fields, such as email, first name, and last name, which can be restrictive in certain scenarios. This feature allows administrators to create users with only a username, making other fields optional. This provides flexibility for systems that don't require complete user profiles upon initial creation for example simplified onboarding flows. This change should be reflected across all user creation interfaces, including the self-registration UI, the management console UI, and the APIs.

Acceptance criteria

• API User Creation:
  • Given: An API call to create a new user is made.
  • When: The API call only includes a username.
  • Then:
    • The user should be created successfully.
    • The response should indicate success.
    • The user's profile should contain the provided username.
    • The users display name is set to the username
  • When: The API call also includes optional fields such as email, firstname, lastname, email verified.
  • Then:
    • The user should be created successfully and the user profile should contain the provided optional fields.
    • The users display name should be set to either email or firstname + lastname
• Management Console User Creation:
  • Given: An administrator is logged into the management console and navigates to the user creation page.
  • When: The administrator enters only a username and attempts to create the user.
  • Then:
    • The user should be created successfully.
    • The system should not display any validation errors related to missing optional fields (email, first name, last name, email verified).
    • The users display name shows the username
  • When: The administrator enters a username and any combination of the optional fields.
  • Then:
    • The user should be created successfully and the user profile should contain the provided optional fields.
    • The users display name shows either the username, email or firstname + lastname
• Self-Registration UI (Login):
  • Given: A user attempts to register through the self-registration UI.
  • When: The user enters only a username and attempts to register.
  • Then:
    • The registration should be successful.
    • The system should not require the user to enter email, first name, or last name.
    • The users display name is taken to show the user, the display name contains the username
  • When: The user enters a username and any combination of the optional fields.
  • Then:
    • The user should be created successfully and the user profile should contain the provided optional fields.
    • The users display name is taken to show the user, the display name contains the username, the email address or firstname + lastname, dependent on the information the user has
• Login without Verified Email:
  • Given: A user has been created with a username and an unverified email address or no email address at all.
  • When: The user attempts to log in using their username and password.
  • Then: The login should be successful.
• Password Reset via Email:
  • Given: A user attempts to reset their password using the "Forgot Password" flow, which relies on email.
  • When: The user has no email address or an unverified email address associated with their account.
  • Then: The system should display an error message indicating that no contact information is available for password reset.
•  Data Validation:
  • Given: A user creation attempt is made through any interface (API, management console, self-registration).
    • When: The username field is empty.
    • Then: The system should display a validation error indicating that the username is required.
  • Given: A user creation attempt is made through any interface.
    • When: The username field is not unique.
    • Then: The system should display a validation error indicating that the username already exists.
• Documentation
  • The documentation is updated to reflect the new optional field behaviour for user creation

Technical Considerations

• Implementation for hosted login v2 only
• Hosted Login v1 will be removed
• Existing v1 APIs will stay as is
• API v2 will change --> make sure all customers are aware of this behaviour change

[hifabienne]

@livio-a do you see any other impacts this might have?

[livio-a]

I've so far checked the following:

• First- / LastName change requires
  • a new profile changed event version to be able to empty them
  • update of email texts (we currently use first and last name instead of just displayname) <- how do we handle this on zitadel.cloud?
    For the email part i have some questions:
• Until now we create an init code for users and their state is initial until they successfully verify it. Do we drop that completely? Even for users with an email?
  • If so we might need to check if current initial users (resp. their events) need some special handling (e.g. notifications handler, ...)
  • Some of the current actions dependant on the initial state: ResendInitialMail, resp. ChangeHumanEmail and every password setting / changing method (relates to Allow setHumanPassword on users without initial Password #4232 and maybe Optimization: if User aready initialized, code from mail doesn't work #2095)
• Do we want to remind users without verified email to verify them during the login (like MFA setup prompt) to be able to reset their password and so on?

@hifabienne or maybe @fforootd has some opinion?

[hifabienne]

Maybe we should make a config, where you can configure if the email should be verified or not. depending on the config we will add this in the login flow or not

[fforootd]

update of email texts (we currently use first and last name instead of just displayname) <- how do we handle this on zitadel.cloud?

Why not just the loginname?

Until now we create an init code for users and their state is initial until they successfully verify it. Do we drop that completely? Even for users with an email?

I agree with @hifabienne we should allow our customers to define if verification is needed for the contact information

Do we want to remind users without verified email to verify them during the login (like MFA setup prompt) to be able to reset their password and so on?

Depending on the configuration but generally speaking yes