When a stale ContentType is fetched, the _add_to_cache() function
didn't detect that `model_class()` returns `None` (which it does by
design). However, the `app_label` + `model` fields can be used instead
to as local cache key. Third party apps can detect stale models by
checking whether `model_class()` returns `None`.
Ticket: https://code.djangoproject.com/ticket/20442
Removing a backend configured in AUTHENTICATION_BACKENDS should not
raise an exception for existing sessions, but should make already
logged-in users disconnect.
Thanks Bradley Ayers for the report.
* py-bcrypt has not been updated in some time
* py-bcrypt does not support Python3
* py3k-bcrypt, a port of py-bcrypt to python3 is not compatible
with Django
* bcrypt is supported on all versions of Python that Django
supports
Thanks to Preston Timmons for the bulk of the work on the patch, especially
updating Django's own test suite to comply with the requirements of the new
runner. Thanks also to Jannis Leidel and Mahdi Yusuf for earlier work on the
patch and the discovery runner.
Refs #11077, #17032, and #18670.
This also updates all dependent functionality, including modelform_factory
and modelformset_factory, and the generic views `ModelFormMixin`,
`CreateView` and `UpdateView` which gain a new `fields` attribute.
The OGRInspectTest.test_time_field does still not succeed with these
databases (even when removing the postgis guard), but at least it's now
possible to setup a datasource.
Also, use Django templating for the dynamic generated JS code and use
more idiomatic coding techniques.
Thanks Matthew Tretter for the report and the patch.
This is provided as a new "validate_max" formset_factory option defaulting to
False, since the non-validating behavior of max_num is longstanding, and there
is certainly code relying on it. (In fact, even the Django admin relies on it
for the case where there are more existing inlines than the given max_num). It
may be that at some point we want to deprecate validate_max=False and
eventually remove the option, but this commit takes no steps in that direction.
This also fixes the DoS-prevention absolute_max enforcement so that it causes a
form validation error rather than an IndexError, and ensures that absolute_max
is always 1000 more than max_num, to prevent surprising changes in behavior
with max_num close to absolute_max.
Lastly, this commit fixes the previous inconsistency between a regular formset
and a model formset in the precedence of max_num and initial data. Previously
in a regular formset, if the provided initial data was longer than max_num, it
was truncated; in a model formset, all initial forms would be displayed
regardless of max_num. Now regular formsets are the same as model formsets; all
initial forms are displayed, even if more than max_num. (But if validate_max is
True, submitting these forms will result in a "too many forms" validation
error!) This combination of behaviors was chosen to keep the max_num validation
simple and consistent, and avoid silent data loss due to truncation of initial
data.
Thanks to Preston for discussion of the design choices.
Before this change, the get_admin_log method would expect User model's
FK to be named `id`. When changing that FK name, admin/index.html
rendering would fail.
This includes:
* Changed the use of id for the use of pk property.
* Added a regression test that fails without the patch.
This commit refs #20088.
The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.
The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.
This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).
Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.
Fixed#17600, fixed#13198, fixed#17025, fixed#17000, fixed#11293.
Since "unless managed" now means "if database-level autocommit",
committing or rolling back doesn't have any effect.
Restored transactional integrity in a few places that relied on
automatically-started transactions with a transitory API.