User creation fails with 500 error when email field is left blank - missing frontend validation

Describe the bug

When creating a new user via the admin interface, certain fields can cause a 500 Internal Server Error due to database unique constraint violations. The server logs show PrismaClientKnownRequestError with code P2002.

Currently, two fields have been identified as problematic:

1. email field — When left blank, it is stored as an empty string "". Since multiple users can have no email, the UNIQUE constraint is violated for the second user.

2. resetCode field — This field is intended for password reset tokens. During user creation, the system appears to populate it with a default value (e.g., "123456"). Since this default value is the same for all new users, the UNIQUE constraint is violated when creating a second user.

To Reproduce

1. Log in as an admin user.
2. Navigate to the user creation page.
3. Fill in the required fields (Username, Password) but leave the Email field empty.
4. Submit the form – the first user is created successfully.
5. Repeat the process for a second user, again leaving Email empty.
6. The second attempt fails with a 500 error (email constraint).

Similarly, for resetCode:

• Even if the email is filled in, the second user creation will fail because the resetCode field is populated with the same default value (e.g., "123456") for all new users.

Expected behavior

The system should handle these fields in a way that prevents constraint violations:

• For email:

  • Either make it a required field with frontend validation (not empty, valid format) and clearly mark it as such in the UI, or
  • Treat an empty email as NULL (not "") to allow multiple users without an email address.

• For resetCode:

  • This field should either not have a UNIQUE constraint, or the system should generate a truly unique value (e.g., a random UUID or hash) for each new user at creation time.

Additional Context

Both issues stem from the same underlying design flaw: the database schema enforces uniqueness on fields that are either not mandatory during user creation or are populated with a non-unique default value.

Screenshots / Logs

Email error:

Unique constraint failed on the fields: (`email`)

ResetCode error:

Unique constraint failed on the fields: (`resetCode`)

Full logs are available below (or attached).

Environment

• MWS version: 0.2.4
• TiddlyWiki version: 5.4.1
• Database: SQLite

Suggested Fix

1. Review all UNIQUE constraints in the Users table to identify which fields are truly required to be unique.
2. For fields that are optional but should be unique when provided (like email), either:
   • Add frontend validation to enforce that they are not empty and follow the correct format, or
   • Allow NULL values and treat empty inputs as NULL instead of "".
3. For fields like resetCode, consider either:
   • Removing the UNIQUE constraint if it is not truly needed, or
   • Auto-generating a unique value (e.g., UUID) on user creation, even if the user never requests a password reset.

Start at the admin user-creation page and trace submission into the Users table/schema, checking how blank email and the resetCode default are persisted in SQLite. Reproduce the two-user cases and inspect the reported Prisma P2002 errors. Done means repeated user creation no longer produces a 500 error and the chosen uniqueness behavior is enforced consistently.