* refactor removing parameters from kwargs when creating a ListSerializer
* insert child
* small rewrite
---------
Co-authored-by: Willem Van Onsem <willem.vanonsem@prosafco.be>
* Propagate 'default' from model_field to serializer field
Fix#7469.
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
* updated field default on serializer according to openapi generation and added that to options action response
* added notes regarding default value propagation from model to serializer field
* updated note
* Update docs/api-guide/fields.md
* Update docs/api-guide/fields.md
* Update docs/api-guide/fields.md
* Update docs/api-guide/fields.md
* Update docs/api-guide/fields.md
* Update docs/api-guide/fields.md
---------
Co-authored-by: John Parton <john.parton.iv@gmail.com>
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
Co-authored-by: Rizwan Shaikh <rshaikh@ces-ltd.com>
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Use subquery to remove duplicates in SearchFilter
* Align SearchFilter behaviour to django.contrib.admin
* Add compatibility with older django/python versions
* Allow search to split also by comma after smart split
* Use generator to build search conditions to reduce iterations
* Improve search documentation
* Update docs/api-guide/filtering.md
---------
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* fix OpenAPIRenderer for timedelta
* added test for rendering openapi with timedelta
* fix OpenAPIRenderer for timedelta
* added test for rendering openapi with timedelta
* Removed usage of field.choices that triggered full table load (#8950)
Removed the `{{ field.choices|yesno:",disabled" }}` block because this triggers the loading of full database table worth of objects just to determine whether the multi-select widget should be set as disabled or not.
Since this "disabled" marking feature is not present in the normal select field, then I propose to remove it also from the multi-select.
* Added Deprecation Warnings for CoreAPI (#7519)
* Added Deprecation Warnings for CoreAPI
* Bumped removal to DRF315
* Update rest_framework/__init__.py
* Update rest_framework/filters.py
* Update rest_framework/filters.py
* Update tests/schemas/test_coreapi.py
* Update rest_framework/filters.py
* Update rest_framework/filters.py
* Update tests/schemas/test_coreapi.py
* Update tests/schemas/test_coreapi.py
* Update setup.cfg
* Update rest_framework/pagination.py
---------
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Update copy right timeline
* Fix NamespaceVersioning ignoring DEFAULT_VERSION on non-None namespaces (#7278)
* Fix the case where if the namespace is not None and there's no match,
NamespaceVersioning always raises NotFound even if DEFAULT_VERSION
is set or None is in ALLOWED_VERSIONS
* Add test cases
* fix OpenAPIRenderer for timedelta
* added test for rendering openapi with timedelta
* added testcase for rendering yaml with minvalidator for duration field (timedelta)
---------
Co-authored-by: Rizwan Shaikh <rshaikh@ces-ltd.com>
Co-authored-by: Lenno Nagel <lenno@namespace.ee>
Co-authored-by: David Smith <39445562+smithdc1@users.noreply.github.com>
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Konstantin Kuchkov <konstantin.kuchkov@gmail.com>
* Fix the case where if the namespace is not None and there's no match,
NamespaceVersioning always raises NotFound even if DEFAULT_VERSION
is set or None is in ALLOWED_VERSIONS
* Add test cases
Removed the `{{ field.choices|yesno:",disabled" }}` block because this triggers the loading of full database table worth of objects just to determine whether the multi-select widget should be set as disabled or not.
Since this "disabled" marking feature is not present in the normal select field, then I propose to remove it also from the multi-select.
* fix: Make the instance variable of child serializer point to the correct list object instead of the entire list when validating ListSerializer
* fix formatting issues for list serializer validation fix
* fix imports sorting for list serializer tests
* remove django 2.2 from docs index (#8982)
* Declared Django 4.2 support in README.md (#8985)
* Fix Links in Documentation to Django `reverse` and `reverse_lazy` (#8986)
* Fix Django Docs url in reverse.md
Django URLs of the documentation of `reverse` and `reverse_lazy` were wrong.
* Update reverse.md
* fix URLPathVersioning reverse fallback (#7247)
* fix URLPathVersioning reverse fallback
* add test for URLPathVersioning reverse fallback
* Update tests/test_versioning.py
---------
Co-authored-by: Jorn van Wier <jorn.van.wier@thunderbyte.ai>
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Make set_value a method within `Serializer` (#8001)
* Make set_value a static method for Serializers
As an alternative to #7671, let the method be overridden if needed. As
the function is only used for serializers, it has a better place in the
Serializer class.
* Set `set_value` as an object (non-static) method
* Add tests for set_value()
These tests follow the examples given in the method.
* fix: Make the instance variable of child serializer point to the correct list object instead of the entire list when validating ListSerializer
* Make set_value a method within `Serializer` (#8001)
* Make set_value a static method for Serializers
As an alternative to #7671, let the method be overridden if needed. As
the function is only used for serializers, it has a better place in the
Serializer class.
* Set `set_value` as an object (non-static) method
* Add tests for set_value()
These tests follow the examples given in the method.
* fix: Make the instance variable of child serializer point to the correct list object instead of the entire list when validating ListSerializer
* fix: Make the instance variable of child serializer point to the correct list object instead of the entire list when validating ListSerializer
* fix formatting issues for list serializer validation fix
* fix: Make the instance variable of child serializer point to the correct list object instead of the entire list when validating ListSerializer
* fix formatting issues for list serializer validation fix
* fix linting
* Update rest_framework/serializers.py
Co-authored-by: Sergei Shishov <sshishov@users.noreply.github.com>
* Update rest_framework/serializers.py
Co-authored-by: Sergei Shishov <sshishov@users.noreply.github.com>
* fix: instance variable in list serializer, remove commented code
---------
Co-authored-by: Mathieu Dupuy <deronnax@gmail.com>
Co-authored-by: Mehraz Hossain Rumman <59512321+MehrazRumman@users.noreply.github.com>
Co-authored-by: Dominik Bruhn <dominik@dbruhn.de>
Co-authored-by: jornvanwier <mail@jornvanwier.com>
Co-authored-by: Jorn van Wier <jorn.van.wier@thunderbyte.ai>
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Étienne Beaulé <beauleetienne0@gmail.com>
Co-authored-by: Sergei Shishov <sshishov@users.noreply.github.com>
* Make set_value a static method for Serializers
As an alternative to #7671, let the method be overridden if needed. As
the function is only used for serializers, it has a better place in the
Serializer class.
* Set `set_value` as an object (non-static) method
* Add tests for set_value()
These tests follow the examples given in the method.
* this commit fixes the usage of a CursorPagination combined with a view
implementing an ordering filter, without a default ordering value.
* former behavior was to fetch the ordering value from the filter, and
raises an error if the value was None, preventing the fallback on the
ordering set on the CursorPagination class itself.
* we reversed the logic by getting first the value set on the class,
and override it by the ordering filter if the parameter is present
* Refactor get_field_info method to include max_digits and decimal_places attributes in SimpleMetadata class
* Add new test to check decimal_field_info_type
* Update rest_framework/metadata.py
---------
Co-authored-by: Mahdi <mahdi@Mahdis-MacBook-Pro.local>
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Ensure CursorPagination respects nulls in the ordering field
* Lint
* Fix pagination tests
* Add test_ascending with nulls
* Push tests for nulls
* Test pass
* Add comment
* Fix test for django30
* Update relations.py
Currently if you define the slug field as a nested relationship in a `SlugRelatedField` while many=False, it will cause an attribute error. For example:
For this code:
```
class SomeSerializer(serializers.ModelSerializer):
some_field= serializers.SlugRelatedField(queryset=SomeClass.objects.all(), slug_field="foo__bar")
```
The POST request (or save operation) should work just fine, but if you use GET, then it will fail with Attribute error:
> AttributeError: 'SomeClass' object has no attribute 'foo__bar'
Thus I am handling nested relation here. Reference: https://stackoverflow.com/questions/75878103/drf-attributeerror-when-trying-to-creating-a-instance-with-slugrelatedfield-and/75882424#75882424
* Fixed test cases
* code comment changes related to slugrelatedfield
* changes based on pre-commit and removed comma which was added accidentally
* fixed primary keys of the mock object
* added more test cases based on review
---------
Co-authored-by: Arnab Shil <arnab.shil@thermofisher.com>
Apart from a few exceptions, django-rest-framework uses the American
English spelling "authorization"/"authorized".
$ git grep -oi authorised | wc -l
2
$ git grep -oi authorized | wc -l
30
Replace the few occurences of the British English spelling with the
American English one.
Allow Request, Response, Field, and GenericAPIView to be subscriptable.
This allows the classes to be made generic for type checking.
This is especially useful since monkey patching DRF can be problematic
as seen in this [issue][1].
[1]: https://github.com/typeddjango/djangorestframework-stubs/issues/299
* Allow usage of Django 2.x path in SimpleRouter
* Use path in Default router
* Update docs/api-guide/routers.md
Co-authored-by: Éric <merwok@netwok.org>
* Update docs/api-guide/routers.md
Co-authored-by: Éric <merwok@netwok.org>
* Add tests also for default router with path
* Use a more relevant attribute for lookup when using path converters
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Éric <merwok@netwok.org>
* Re-prefetch related objects after updating
* Fix flake8 format
* Use _prefetch_related_lookups and refine test cases
* Add more test cases and refine prefetch checking
Without this, Django's ValidationErrors will bypass the error collection
from ListField's children.
Here is an example that illustrates this change.
Consider a Serializer that uses ListField like this:
```python
class SomeSerializer(serializers.Serializer):
uuids = serializers.ListField(
child=serializers.PrimaryKeyRelatedField(
queryset=Model.objects.something(),
validators=[SomeCustomValidator()]
)
)
```
Validating data that looks like this works fine:
```python
{uuids: ['some-valid-uuid', 'some-valid-uuid']}
```
Raising a DRF ValidationError for one of the children works fine, giving
an error object like:
```python
{'uuids': {0: ErrorDetail(string='Some validation error')}}
```
Raising a Django ValidationError for one of the children works
differently (which serializers.PrimaryKeyRelatedField can do in some
cases, like when the uuid is malformed). It gives an error object like:
```python
{'uuids': ["'X' is not a valid UUID."]}
```
Handling Django's ValidationErrors in ListField explicitly (like in this
pull request), will maintain a regular error interface in this case:
```python
{'uuids': {0: ErrorDetail(string="'X' is not a valid UUID.")}}
```
Scripts with type="application/json" or "text/plain" are not executed, so we can
use them to inject dynamic CSRF data, without allowing inline-script execution
in Content-Security-Policy.
* Fixes 'RelatedManager' object is not iterable in ListSerializer.to_representation.(#8726)
* Change to only BaseManager
* Commit unit test
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Format import
* Format import
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* FloatField will crash if the input is a number that is too big
* Added Unit test for float field overflow error catch
* Removed random import
* Removed additional imported ValidationError
* Update rest_framework/fields.py
* Update tests/test_fields.py
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Added normalize parameter to DecimalField to be able to strip trailing zeros. Fixes#6151.
* Updated docs to include normalize option on DecimalField
* Fixed linting error in test_fields
* Removed comment and renamed normalize to normalize_output as suggested in code review
Co-authored-by: Tom Christie <tom@tomchristie.com>
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.
`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.
