Unify the setup initialization endpoint’s error contract to match the rest
of the project and keep the frontend unchanged.
Changes
- controller/setup.go: Return HTTP 200 with {success:false, message} for all
predictable errors in POST /api/setup, including:
- already initialized
- invalid payload
- username too long
- password mismatch
- password too short
- password hashing failure
- root user creation failure
- option persistence failures (SelfUseModeEnabled, DemoSiteEnabled)
- setup record creation failure
- web/src/components/setup/SetupWizard.jsx: Restore catch handler to the
previous generic toast (frontend logic unchanged).
- web/src/helpers/utils.jsx: Restore the original showError implementation
(no Axios response.data parsing required).
Why
- Keep API behavior consistent across endpoints so the UI can rely on the
success flag and message in the normal .then() flow instead of falling
into Axios 4xx errors that only show a generic "400".
Impact
- UI now displays specific server messages during initialization without
frontend adaptations.
- Note: clients relying solely on HTTP status codes for error handling
should inspect the JSON body (success/message) instead.
No changes to the happy path; initialization success responses are unchanged.
The User model applies `validate:"max=12"` to the `Username` field, but the
initial setup flow did not validate this constraint. This allowed creation
of a root user with an overly long username (e.g. "Uselessly1344"), which
later caused every update request to fail with:
Field validation for 'Username' failed on the 'max' tag
This patch adds an explicit length check in `controller/setup.go` to reject
usernames longer than 12 characters during setup, keeping validation rules
consistent across the entire application.
Refs: #1214
