Refs #34429: Following the implementation allowing the setting of
unusable passwords via the admin site, the `BaseUserCreationForm` and
`UserCreationForm` were extended to include a new field for choosing
whether password-based authentication for the new user should be enabled
or disabled at creation time.
Given that these forms are designed to be extended when implementing
custom user models, this branch ensures that this new field is moved to
a new, admin-dedicated, user creation form `AdminUserCreationForm`.
Regression in e626716c28.
Thanks Simon Willison for the report, Fabian Braun and Sarah Boyce for
the review.
This also caused un-ordered sliced prefetches to crash as they rely on Window.
Regression in e16d0c176e that made OrderByList
piggy-back ExpressionList without porting the empty handling that the latter
provided.
Supporting explicit empty ordering on Window functions and slicing is arguably
a foot-gun design due to how backends will return undeterministic results but
this is a problem that requires a larger discussion.
Refs #35064.
Thanks Andrew Backer for the report and Mariusz for the review.
Aggregation optimization didn't account for not referenced set-returning annotations on Postgres.
Co-authored-by: Simon Charette <charette.s@gmail.com>
LocaleMiddleware didn't handle the ValueError raised by
get_supported_language_variant() when language codes were
over 500 characters.
Regression in 9e9792228a.
This is the exact same issue as refs #30408 but for creating a model with a
constraint containing % escapes instead of column addition. All of these issues
stem from a lack of SQL and parameters separation from the BaseConstraint DDL
generating methods preventing them from being mixed with other parts of the
schema alteration logic that do make use of parametrization on some backends
(e.g. Postgres, MySQL for DEFAULT).
Prior to the addition of Field.db_default and GeneratedField in 5.0
parametrization of DDL was never exercised on model creation so this is
effectively a bug with db_default as the GeneratedField case was addressed by
refs #35336.
Thanks Julien Chaumont for the report and Mariusz Felisiak for the review.
Previously the order was always extra_fields + model_fields + annotations with
respective local ordering inferred from the insertion order of *selected.
This commits introduces a new `Query.selected` propery that keeps tracks of the
global select order as specified by on values assignment. This is crucial
feature to allow the combination of queries mixing annotations and table
references.
It also allows the removal of the re-ordering shenanigans perform by
ValuesListIterable in order to re-map the tuples returned from the database
backend to the order specified by values_list() as they'll be in the right
order at query compilation time.
Refs #28553 as the initially reported issue that was only partially fixed
for annotations by d6b6e5d0fd.
Thanks Mariusz Felisiak and Sarah Boyce for review.
