`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
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).
PR #7531 resolved issue #7433 by updating `ErrorDetails.__eq__` to correctly
handle the `NotImplemented` case. However, Python 3.9 continues to issue the
following warning:
DeprecationWarning: NotImplemented should not be used in a boolean context
This is because `__ne__` still doesn't handle the `NotImplemented` case
correctly. In order to avoid this warning, this commit makes the same change
for `__ne__` as previously made for `__eq__`.
Add a backwards compatibility shim for Django versions that have no (or an incompatible)
django.utils.http.parse_header_parameters implementation.
Thanks to Shai Berger for review.
Co-authored-by: Jaap Roes <jroes@leukeleu.nl>
If you set a custom timezone for a DateTimeField, the function
self.default_timezone() is still called, since fallback params to
getattr are still evaluated.
This rewrites to use hasattr, so the fallback case is only executed if
it will actually be used. If you render a lot of DateTimeFields in a
serializer, the time spent evaluating default_timezone() once for each
of them can accumulate to quite a bit, which is just unused work in the
case where timezone is already specified on the field.
* Handle unset fields with 'many=True'
The docs note:
When serializing fields with dotted notation, it may be necessary to
provide a `default` value if any object is not present or is empty
during attribute traversal.
However, this doesn't work for fields with 'many=True'. When using
these, the default is simply ignored.
The solution is simple: do in 'ManyRelatedField' what we were already
doing for 'Field', namely, catch possible 'AttributeError' and
'KeyError' exceptions and return the default if there is one set.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Closes: #7550
* Add test cases for #7550
Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add retain test data on follow=True
* Simplify TestAPITestClient.test_follow_redirect
Inspired from Django's ClientTest.test_follow_307_and_308_redirect
* Add 307 308 follow redirect test
Propagate the nullability of underlying model fields in ModelSerializer
when those fields are marked as read only. This ensures the correct
generation of OpenAPI schemas.
Fix#8041.
* Add distinction between request and response serializers
* Add docs
* document new functions in schemas.md
* add a test case for different request vs response objects
* Correct formatting for flake8
Co-authored-by: Shaun Gosse <shaun.gosse@emburse.com>
HTML responses generated by the Browsable API otherwise generate
inconsistent ETAGs -- due to the presence of CSRF tokens in the response
-- even when the API is read-only, (and as such when the response
contains no resource-modifying forms, i.e. neither POST nor PUT forms,
which might require the CSRF token).
While the template was appropriately including CSRF tokens only within
POST and PUT forms, its AJAX overlay included the CSRF token in *every*
response, regardless of whether it would be needed.
This change brings the logic of the `script` block into line with that
of the rest of the template -- and such that read-only APIs (and really
the Browsable API pages of *any* read-only resources) will not
needlessly include the CSRF token, and will now be safely cachable -- by
both back-end systems and by the user agent.
* Add failing tests for ordering filter with model property
* Fix get_default_valid_fields of OrderingFilter
* Filter model properties in get_default_valid_fields of OrderingFilter
* Fix JSONBoundField usage on nested serializers (#6211)
* Unify JSONBoundField as_form_field output between py2 and py3
When using json.dumps with indenting, in python2 the default formatting
prints whitespace after commas (,) and python3 does not. This can be
unified with the separators keyword argument.
* Add failing test when rendering to json a schema with timedelta
* Fix JSONOpenAPIRenderer for fields with default=timedelta()
* fix isort
* fix test for python 3.5
Co-authored-by: Pierre Chiquet <pierre.chiquet@ubikey.fr>
When I apply a theme to the bootstrap used in the project, boolean inputs are out of line with the rest of the form. With this small payment, this no longer occurs.
* Handle None in to_representation()
* Return None as '' in to_representation() when coerce_to_string=True
* Handle '' as None in to_internal_value(), for symmetry with
to_representation(), and because the empty concept doesn't make sense
for Decimal.
In the `to_internal_value` method of the primary key and slug related fields, `TypeError`s and `ValueError`s are caught from `self.get_queryset().get(...)` and presented to the user. This works fine for most cases, but can cause problems if the exception is coming from `self.get_queryset()` rather than from the `.get(...)`.
It means errors in the `get_queryset` method can be hidden and presented back to the user as though, for example, the input provided to the `to_internal_value` was the wrong type, whereas in reality there's a bug in the `get_queryset` method and therefore it should bubble up and be exposed as a server error.
I've decided to fix this because twice now I've had to debug why I'm seeing `invalid_type` errors from my serializer (errors like `wrong pk type - int` when the `pk` type on my model is `int`) when the real problem was a bug in my custom `get_queryset` method.
The test suite raises warnings when tested against Python 3.9
`DeprecationWarning: NotImplemented should not be used in a boolean context`
Where `r` returns `NotImplemented` then this change returns `NotImplemented` first to avoid the comparison test.
Fixes#7417.
Fixes all these issues seen with `tox -e py38-django31`:
```
/Users/chainz/Documents/Projects/django-rest-framework/tests/test_request.py:208: RemovedInDjango40Warning: Passing None for the middleware get_response argument is deprecated.
SessionMiddleware().process_request(self.wrapped_request)
tests/test_requests_client.py: 1 test with warning
tests/test_testing.py: 4 tests with warnings
tests/test_throttling.py: 1 test with warning
tests/authentication/test_authentication.py: 4 tests with warnings
tests/browsable_api/test_browsable_api.py: 4 tests with warnings
/Users/chainz/Documents/Projects/django-rest-framework/rest_framework/authentication.py:139: RemovedInDjango40Warning: Passing None for the middleware get_response argument is deprecated.
check = CSRFCheck()
```
* url() is deprecated in Django 3.1
* update given feedbacks on url() is deprecated in Django 3.1
* Fix test_urlpatterns.py to continue testing mixed re_path() and path()
* Fix one missed reference
Co-authored-by: sanjusci <sanju.sci9@gmail.com>
Django 3.1 adds a new generic JSONField to replace the PostgreSQL-specific one. This adds support for the new field type, which should behave the same as the existing PostgreSQL field.
Django's new JSONField also includes support for a custom "decoder", so add support for that in the serializer field.
