Files
pgadmin4/web
Dave Page 35d68c47eb fix: follow Flask-Security-Too 5.8.2's corrected is_locked() semantics (#10256)
Flask-Security-Too 5.8.2, released on 12 August 2026, fixed a long-standing
inversion in its login forms: `LoginForm.validate()` previously read a `True`
return from `UserMixin.is_locked()` as "not locked, carry on", and the base
implementation unconditionally returned `True`. Our `User.is_locked()` was
written against that inverted convention, so as soon as CI began resolving
5.8.2 through the loose `Flask-Security-Too==5.8.*` pin, an unlocked user
returned `True`, form validation failed, the login POST redirected with a 302
and every subsequent request arrived as `AnonymousUser`. The server-mode data
isolation tests caught it, though the breakage is not limited to tests: on
5.8.2 nobody could log in at all.

`User.is_locked()` now returns `True` when the account is locked, matching the
corrected upstream contract, and the dependency is floored at 5.8.2 so that we
cannot silently resolve a release which reads the value backwards. The two
conventions are mutually exclusive, hence a floor rather than a version check
in the model. The regression tests are updated to assert the fixed contract.
2026-08-14 11:17:09 +01:00
..
2022-04-01 17:22:16 +05:30
2026-01-05 13:33:45 +05:30
2026-01-05 13:33:45 +05:30
2026-01-05 13:33:45 +05:30
2026-07-28 12:08:09 +05:30