Edit/add user via WebUI problem (Data did not pass vlaidation - Domain* is required - but selected)

Issue Description

When editing a user to for eq. add/remove group membership, the save keep failing with the “Domain” field having the error: This Field is required
that is after I’ve already selected a domain from the check list.

Expected Behavior

Save is succesfull

Actual Behavior

Domain*
Identifier for the domain this account belongs to. This is used to determine the email address of the account, which is formed as name@domain.

hevis.co.za

This field is required.

Reproduction Steps

  1. configure/load keys via a AI CLI tooling
  2. try to understnd/edit via the WebUI
  3. tr to “Save”

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

FoundationDB

Blob Storage

S3-compatible

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

Let me look into this WebUI validation issue with the Domain field.

I found the key validation logic. The validateRequired function checks if required objectId type fields are empty. Now let me look at what exactly happens with the domainId field during edits and whether there’s a known bug around this.

I haven’t been able to reproduce this on an account created in the WebUI, so I suspect it’s specific to how the principal was stored when it was created by your CLI tooling: if the name or domain ended up in a shape the edit form’s domain selector doesn’t bind to, the required check can fire even though a value looks selected.

Does it also happen for a user you create entirely in the WebUI, or only for the CLI-created one? And can you paste the stored principal (stalwart-cli account display , or the JSON you used to create it), in particular whether the account name already includes the @domain suffix and how the domain is stored? With that I can match it to the form’s expected shape and fix whichever side is wrong.

Hmmm… yeah, looks like it’s either fixed in the last version, or there were some other caching thing that might’ve caused this. as today I can’t seem to trigger it as reliably as I could when I logged this ticket.