Conversation
tischsoic
force-pushed
the
IBX-11959-password-requirements-info
branch
from
September 8, 2026 08:02
56a91bb to
f5503ff
Compare
tischsoic
force-pushed
the
IBX-11973-account-screens-validation
branch
from
September 8, 2026 08:05
8e0fce5 to
d00527a
Compare
albozek
approved these changes
Sep 8, 2026
dew326
approved these changes
Sep 10, 2026
Base automatically changed from
IBX-11959-password-requirements-info
to
6.0
September 11, 2026 06:12
tischsoic
force-pushed
the
IBX-11973-account-screens-validation
branch
from
September 14, 2026 10:48
d00527a to
48375cc
Compare
barbaragr
force-pushed
the
IBX-11973-account-screens-validation
branch
from
September 14, 2026 11:21
48375cc to
5010ef6
Compare
barbaragr
requested changes
Sep 14, 2026
Contributor
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
force-pushed
the
IBX-11973-account-screens-validation
branch
from
September 15, 2026 08:52
3255088 to
6c38902
Compare
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>
…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>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.






Related PRs:
IBX-11959-password-requirements-info; only the top four commits belong to this PR.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 inlogin.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_simplenever derives the DS input'serrorprop from the field's validity. Passing it throughform_rowreddens 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 everyBadCredentialsException, hiding which field was empty. Without it this screen falls back to the banner.For QA:
/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./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./admin/user/forgot-password/login(an email matching several accounts) — same on submit with an empty field.Documentation: