* 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>
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
* tests: inherit FakeResolverMatcher from django.urls.ResolverMatcher in tests/test_versioning.py
* tests: inherit from rest_framework.versioning.BaseVersioning in tests/test_reverse.py
* fix: isort
---------
Co-authored-by: Piotr Szyma <pszyma@opera.com>
* 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>
* 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>
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).
* 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
