Skip to content

IBX-11973: Added validation to login and forgot password screens - #2058

Open
tischsoic wants to merge 10 commits into
6.0from
IBX-11973-account-screens-validation
Open

tischsoic wants to merge 10 commits into
6.0from
IBX-11973-account-screens-validation

Conversation

@tischsoic

@tischsoic tischsoic commented Sep 3, 2026

Copy link
Copy Markdown
Contributor
🎫 Issue IBX-11973

Related PRs:

Description:

All three reported issues; validation stays on the backend.

Sign in button. It was disabled until both fields had a value (:disabled="true" plus a keyup/change toggle in login.js). Both are gone, so the button is active as the design shows. Native browser validation still stops an empty submit.

Forgot password. The constraint violation was printed under the field but the input itself stayed neutral, because form_widget_simple never derives the DS input's error prop from the field's validity. Passing it through form_row reddens the input and its label alongside the message, the way an invalid field looks elsewhere in the back office, on both the email and the login variant.

The second commit reverts a first attempt that validated in the browser — kept in history since the ticket asks for it, but out of scope for now.

Empty fields on Sign in. The form is now novalidate, so the browser no longer blocks the submit and the backend answers. Blank fields come back marked invalid with a message underneath, like forgot password; the banner is kept for failures that are not a blank field, so a wrong password still reads as "Bad credentials." rather than pointing at a field. This needs ibexa/user#143 — the failure handler flattened every BadCredentialsException, hiding which field was empty. Without it this screen falls back to the banner.

For QA:

  1. /admin/login — Sign in is active on load. Submit with both fields empty: both are marked invalid with a message each and no banner. Fill only one: only the empty one is marked. Wrong password: "Bad credentials." banner, neither field marked. Valid credentials sign in as before.
  2. /admin/user/forgot-password — submit with the field empty: it turns red and shows "This value should not be blank."; a real address sends the reset link as before.
  3. /admin/user/forgot-password/login (an email matching several accounts) — same on submit with an empty field.

Documentation:

Base automatically changed from IBX-11959-password-requirements-info to 6.0 September 11, 2026 06:12
@tischsoic
tischsoic force-pushed the IBX-11973-account-screens-validation branch from d00527a to 48375cc Compare September 14, 2026 10:48
@barbaragr
barbaragr force-pushed the IBX-11973-account-screens-validation branch from 48375cc to 5010ef6 Compare September 14, 2026 11:21

@barbaragr barbaragr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Email field doesn't have red outline when validation is on:

Image

@barbaragr

barbaragr commented Sep 14, 2026

Copy link
Copy Markdown
Contributor
Screenshot 2026-09-14 at 15 50 49

Same situation for set new password, validation is inconsistent. If this case is out of scope of this PR, let me know i will report it separately.

@tischsoic
tischsoic requested a review from barbaragr September 15, 2026 08:40
tischsoic and others added 8 commits September 15, 2026 10:52
The Sign in button is no longer disabled until both fields are filled;
empty or malformed fields are now reported inline on submit, the same way
the rest of the back office does it, instead of native browser bubbles.

Backend errors on the forgot password screens now also mark the input
invalid, following the pattern IBX-11959 introduced on Set new password —
its error-row macro is extracted to a shared account partial.

Co-Authored-By: Claude <noreply@anthropic.com>
Validation goes back to the backend: the forgot password screens post
their empty value, and the constraint violation now also marks the input
invalid instead of only printing the message. Native browser validation
stays as the safety net on the login form.

This leaves the Set new password screen untouched, so its error-row macro
no longer needs extracting.

Co-Authored-By: Claude <noreply@anthropic.com>
The script itself was already deleted; the login and reset password
entries still pointed at it.

Co-Authored-By: Claude <noreply@anthropic.com>
An invalid field reddens both its input and its label elsewhere in the
back office; the forgot password screens only reddened the input.

Co-Authored-By: Claude <noreply@anthropic.com>
Clicking Sign in with an empty field now always submits — the browser no
longer blocks it — and the field comes back marked invalid with a message
beneath it, matching the forgot password screen. The banner is kept for
failures that are not a blank field, so a wrong password still reads as
"Bad credentials." rather than pointing at one of the fields.

Requires ibexa/user to preserve which field was blank.

Co-Authored-By: Claude <noreply@anthropic.com>
Fields rendered through the Symfony form theme also carry the legacy
ibexa-input class, whose border rule sits later in the stylesheet at the
same specificity as ids-input--error and therefore won the cascade — the
field kept its neutral outline while only the label and the message
turned red. The login screen was unaffected because it renders the
design-system input directly, without that class.

Also marks the label on the Set new password screen, which reported the
same inconsistency.

Co-Authored-By: Claude <noreply@anthropic.com>
…submit

Submitting the Set new password form with both fields empty ticked all
requirements and showed nothing, because the resulting violation is
mapped to the root form rather than to the repeated field, so the
template saw no errors at all and treated the submission as one where
every rule had passed.

Root-level violations are now collected too, and are shown on the new
password field when nothing more specific applies — the mismatch case
still reports only "Passwords do not match." rather than also claiming
the value is blank.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
@barbaragr
barbaragr force-pushed the IBX-11973-account-screens-validation branch from 3255088 to 6c38902 Compare September 15, 2026 08:52

@barbaragr barbaragr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New password field is not validated:

Image

Submitting with nothing filled in produces a single violation against the
repeated field as a whole, so only the new password box was marked while
the confirmation next to it stayed neutral. Both are now marked, with the
message still printed once.

Co-Authored-By: Claude <noreply@anthropic.com>
@tischsoic
tischsoic requested a review from barbaragr September 16, 2026 09:35
…ion lands

Where Symfony attaches the empty-value violation depends on its version:
7.4.19 added a camelised fallback in ViolationMapper, which maps the
newPassword path onto the new_password child, while older releases left it
on the root form. The template read only one of those places, so the new
password field stayed unmarked on installations with the newer release.

All three locations are now collected, and any error that is not a
password-requirement failure marks both fields, so the pair is reported
consistently no matter which node Symfony chose.

Co-Authored-By: Claude <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants