Aman-Mittal opened a new issue, #753: URL: https://github.com/apache/fineract-backoffice-ui/issues/753
### Summary On **Create User**, the Password and Repeat Password fields aren't validated against each other or against the password policy. With different values in the two fields, no inline error appears and **Save stays enabled**. The mistake only surfaces as a server 400 shown in a toast. ### Environment - App: https://aman-mittal.github.io/fineract-backoffice-ui (deployed `main`), route `/security/users/create` - Backend: `sandbox.mifos.community`, tenant `default` - Role: superuser (`mifos`) - Chrome 1440×900, 2026-10-16 ### Preconditions `CREATE_USER`. ### Steps to reproduce 1. **Security → Users → Create User**. 2. Fill in username, names, email, office and a role. 3. Enter two **different** values in Password and Repeat Password, then tab out. 4. Observe the form, then click **Save**. ### Expected behavior - An inline "Passwords do not match" under Repeat Password as soon as it loses focus, with the field marked `aria-invalid="true"`. - Save disabled (or blocked) while they differ. - The policy (length 12–50, upper/lower/digit/special, no spaces, no consecutive repeats) shown as helper text and checked before submit, so the user doesn't learn it by trial and error. ### Actual behavior - No inline message after blurring Repeat Password. Save is **enabled**. - Save sends `POST /users` → **400** with two errors: `validation.msg.user.password.does.not.match.regexp` and `validation.msg.user.repeatPassword.not.equal.to.password`. - The only feedback is a toast. Nothing is attached to either field, and the toast disappears by itself. ### Evidence Live session: `saveDisabled: false` read from the Save button with mismatched values, then the 400 response above. ### Impact Admin friction: each guess at the policy costs a round trip, and a toast that disappears by itself is easy to miss. For screen-reader users, errors not tied to fields fail WCAG 3.3.1 (Error Identification). ### Suggested investigation Add a cross-field validator on the form group (`repeatPassword === password`) and a pattern validator mirroring the platform policy, ideally sourced from **System → Password Preferences** (`GET /passwordpreferences`) rather than hard-coded, since the policy is tenant-configurable. Map the two server codes above to inline field errors as a fallback. ### Verification status Reproduced. ### Related endpoints `POST /users`, `GET /passwordpreferences` ### Acceptance criteria - Mismatched values show an inline error and keep Save disabled. - A password violating the active policy shows which rule failed before submit. - If the server still rejects it, the error appears on the field, not only in a toast. ### Related issues Companion to the plaintext-echo issue filed alongside this one. #492 (a user can't change their own password) is the self-service side of the same form logic. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
