Importing anything `rest_framework` causes `django.test` to be imported.
This is because DRF registers a receiver on the
`django.test_signals.setting_changed` signal.
This is not really a problem, but it is good to avoid this because it
bloats the memory with unnecessary modules (e.g. `django.test`,
`django.core.servers.basehttp`, `socketserver`) and increases the
startup time. It also doesn't feel right to import test code into
non-test code.
Try to import the signal from a core module if possible.
Note that there's another `django.test` import in `MultiPartRenderer`,
however this import is done lazily only if the functionality is used so
can be easily avoided.
- Replace the broken Bootswatch-Link with an Jsdelivr-Link as suggested at https://bootswatch.com/help/
- Updated the stated Bootstrap version
- Added a note that the Bootstrap version must match the default one
Co-authored-by: Tom Christie <tom@tomchristie.com>
We depend on pytz, but until late last year we got it implicitly through
depending on Django. Since their release 4.0, however, they no longer
depend on pytz; commit 250479dc3 added the dependency directly to our
metadata in setup.py, but the documentation about dependencies (most
importantly, the instructions for new contributors) was left untouched.
This commit updates the new contributor instructions to suggest an
"editable installation" of the project at the step that previously had
users manually install Django. In this mode, pip fetches and installs
the project dependencies automatically (so in the unlikely event we grow
another dependency, that doc doesn't need to be changed again) and makes
the project available to the virtualenv's python as a normal package,
but doesn't require reinstallation for mundane edits.
`PendingDeprecationWarning` means "we plan to deprecate, but haven't
yet." A feature that's to be deleted in the next release is not planned
to be deprecated; it **is** deprecated.
> Base class for warnings about features which are obsolete and expected
> to be deprecated in the future, but are not deprecated at the moment.
>
> This class is rarely used as emitting a warning about a possible
> upcoming deprecation is unusual, and DeprecationWarning is preferred for
> already active deprecations.
https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning
Co-authored-by: Tom Christie <tom@tomchristie.com>
When DRF 3.14 is released, these exception classes will be meaningless,
so we can delete them (this has always been done).
A previous PR removed the last incidence of `RemovedInDRF313Warning`,
but didn't outright delete the class for fear of shipping a breaking
change: https://github.com/encode/django-rest-framework/pull/8589
* Version 3.14.0
* Update docs/community/release-notes.md to use proper links.
Co-authored-by: Adam Johnson <me@adamj.eu>
* Add community announcement page for version 3.14
* Remove deprecated NullBooleanField.
* Change openapi _get_reference removal to 3.15
This deprecation was never released in the 3.13.x series and therefore
can't be removed at the same time the replacement is released.
* Removing deprecated openapi methods.
Co-authored-by: Adam Johnson <me@adamj.eu>
* Change semantic of OR of two permission classes
The original semantic of OR is defined as: the request pass either of the two has_permission() check, and pass either of the two has_object_permission() check, which could lead to situations that a request passes has_permission() but fails on has_object_permission() of Permission Class A, fails has_permission() but passes has_object_permission() of Permission Class B, passes the OR permission check. This should not be the desired permission check semantic in applications, because such a request should fail on either Permission Class (on Django object permission) alone, but passes the OR or the two.
My code fix this by changing the semantic so that the request has to pass either class's has_permission() and has_object_permission() to get the Django object permission of the OR check.
* Update rest_framework/permissions.py
* Update setup.cfg
Co-authored-by: Mark Yu <markyu98@outlook.com>
Co-authored-by: Tom Christie <tom@tomchristie.com>
* Fixes that namespaced views now also appear in the extra actions
Before this fix, namespaced views would not appear in the extra actions. With this fix they do.
* Flake fix
In the "Creating custom mixins" documentation, the code example recommends using
```python
if self.kwargs[field]
```
However, if the correct field is not present in kwargs, a KeyError arises.
A more secure option is tu use .get() to validate that the field is contained in the kwargs dictionary:
```python
if self.kwargs.get(field)
```
I found it unclear how the model was determined for `DjangoModelPermissions`. The docs say you need a `queryset` or `get_queryset`, but not that the value returned from those is what determines the model that is used.
Per the deprecation warnings (which have been raised since DRF 3.11),
`set_context()` was planned not to be supported in DRF 3.13. I think we
can safely delete it, in favor of `requires_context`.
From the 3.11 announcement:
> Previous our approach to this was that implementations could include a
> `set_context` method, which would be called prior to validation. However
> this approach had issues with potential race conditions. We have now
> move this approach into a pending deprecation state. It will continue to
> function, but will be escalated to a deprecated state in 3.12, and
> removed entirely in 3.13.
Why keep `RemovedInDRF313Warning` around?
=========================================
It's a bit odd that version 3.13 includes an exception class describing
things which are to be deleted in 3.13, but I've opted to keep the (now
unreferenced) class around, for fear of breaking others' setup.
(For example, if projects have a `filterwarnings` setup meant to
intercept `rest_framework.RemovedInDRF313Warning`, an error will be
thrown due to an unresolvable reference).
