* 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>
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
Thanks to Jon Dufresne (@jdufresne) for review.
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Rizwan Mansuri <Rizwan@webbyfox.com>
* Fix issue1811: take limit_choices_to into account with FK
* Issue 1811: Add tests to illustrate issue
* Filter queryset only if limit_choices_to exists
* Move test_relations_with_limited_querysets file within test_relations_pk
* move limit_choices_to logic from relations.py to utils/field_mapping.py
* move limit_choices_to above other check to avoid conflicts
* Identify code that needs to be pulled out of/removed from compat.py
* Extract modern code from get_names_and_managers in compat.py and remove compat code
* Extract modern code from is_authenticated() in compat.py and remove.
* Extract modern code from is_anonymous() in compat.py and remove
* Extract modern code from get_related_model() from compat.py and remove
* Extract modern code from value_from_object() in compat.py and remove
* Update postgres compat
JSONField now always available.
* Remove DecimalValidator compat
* Remove get_remote_field compat
* Remove template_render compat
Plus isort.
* Remove set_many compat
* Remove include compat
These two tests were previously added in
7d79cf35b7
but we have now discovered that there are not actually two separate
cases, there was just a bug in the code that made it look that way.
This also removes a redundant check to see if `DecimalValidator` was
defined.
Previously, all validators set on a DecimalField in Django would be
stripped when converted to a Django REST framework field. This was
because any validator that was an instance of `DecimalValidator` would
be removed, and when `DecimalValidator` wasn't supported (so it was
`None`), all validators would be removed.
This fixes the issue by only removing the `DecimalValidator` instances
if the `DecimalValidator` is supported.
In the automatically applied UniqueValidator, use the error message from
error_messages defined in the model instead of the generic default
UniqueValidator message.
This fixes#2878.
