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.
* Make `NullBooleanField` subclass `BooleanField`
This removes a lot of the redundancy that was in place becuase we
were not doing this. This maintains the `None` initial value that
was previously present, as well as disallowing `allow_null` to be
passed in.
* Remove special case for mapping `NullBooleanField`
In newer versions of Django, the `NullBooleanField` is handled the
same way as a `BooleanField(null=True)`. Given that we also support
that combination, and that our own `NullBooleanField` behaves in the
same manner, it makes sense to remove the special casing that exists
for it.
* Add test for BooleanField(null=True, choices)
* Remove special case for NullBooleanField
* Adjust mapping tests for NullBooleanField
* Fixed linting error
* Raise deprecation warning when NullBooleanField is used
* Fix linting issue in imports
* Fix ModelSerializer unique_together field sources
Updates ModelSerializer to check for serializer fields that map to the
model field sources in the unique_together lists.
* Ensure field name ordering consistency
* SearchFilter to support Custom query Transforms
Since Some fields support `__` as a custom Transform for query lookups we needed to update the m2m checking code to handle search_fields that contain __ that are not relationships.
* Update documentation on SearchFilter to include references to JSON and HStore Fields.
Previously it was only mapping the `type` and `format`, even though
for some field types (like a `MultipleChoiceField`) we map more
than just these. And for some fields (like a `ChoiceField`) we do
not map the `type` at all.
* serializers: removes no longer needed compat checks
UUIDField and DurationField are both supported in all supported Django
versions.
IPAddressField was removed in Django 1.9, which is no longer supported.
* serializers: move related code closer together
This way it's easier to see all of the mappings in one place.
* serializers,docs: remove some DRF 2.x references
The last release of DRF 2.x was 5 years ago, it seems fine to remove
these references now.
* Version 3.11
* Added notes on OpenAPI changes for 3.11.
* Minor docs tweaking
* Update package version and supported versions
* Use a lazy import for django.test.client.encode_mutlipart. Closes#7078
* Expand declared filtering tests
- Test declared filter ordering
- Test multiple inheritance
* Fix serializer multiple inheritance bug
* Improve field order test to check for field types
* Raise framework-specific deprecation warnings
- Use `RemovedInDRF313Warning` instead of DeprecationWarning
- Update to follow deprecation policy
* Pass serializer instead of model to validator
The `UniqueTogetherValidator` may need to access attributes on the
serializer instead of just the model instance. For example, this is
useful for handling field sources.
* Fix framework deprecation warning in test
* Remove outdated validator attribute
Refs #6846
This provides a way for pagination classes to add pagination properties (`count`, `next`, `results` etc.) to OpenAPI response schemas.
A new method `get_paginated_response_schema()` has been added to `BasePagination`. This method is intended to mirror `get_paginated_response()` (which takes a `list` and wraps it in a `dict`).
Hence, `get_paginated_response_schema()` takes an unpaginated response schema (of type `array`) and wraps that with a schema object of type `object` containing the relevant properties that the pagination class adds to responses.
The default implementation of `BasePagination.get_paginated_response_schema()` simply passes the schema through unmodified, for backwards compatibility.
This is the first part of #6846.
Previously, the response schema for list views was an object representing a single item. However, list views return a list of items, and hence it should be an array.
Further work will need to be done to support how pagination classes modify list responses.
There should be no change for views not determined to be list views.
