Closes#5237
Generics/ModelViewset performs filtering on: list, retrieve, put, patch and destroy (plus method equivalents).
i.e. on list plus anything that calls `get_object`.
This PR makes schema generation follow that.
It adds `AutoSchema._allows_filters()` which can be overridden in subclasses.
I’ve made this initially “private” so we can make quick changes if needs be in a 3.7.1 etc.
The documentation generator calls view.get_serializer() in order to
inspect it for documentation generation. However, if get_serializer()
throws an APIException (e.g. PermissionDenied), it doesn't get caught at
the call site, but instead propagates up and aborts the entire view.
With the try/except in this commit, the documentation generator instead
gratiously ignores that particular view and moves on to the next one
instead. Practical concequences of this commit is that the docs no
longer break if any view's get_serializer(..) throws an APIException.
* Changes to the paginator defaults and settings
Require a default paginator be specified when using the page size
setting.
https://github.com/encode/django-rest-framework/issues/5168
* DRF-5168 import warnings
missed this in last commit
* Add a system checks file
Add a check for pagination settings for the 3.7 upgrade cycle.
* more compatible import approach
* missing bactic
* revised language and approach to import the system check
Adds a rest framework app config.
* Adjust doc wording
## Description
The `choices` field for the `ChoiceField` class should be able to be edited after `ChoiceField.__init__` is called.
```
field = ChoiceField(choices=[1,2])
field.choices = [1] # Should no longer allow `2` as a choice
```
Currently, you must update `choices`, `grouped_choices`, and `choice_strings_to_values` to achieve this. This P/R keeps `grouped_choices` and `choice_strings_to_values` in sync whenever the `choices` are edited.
* Add tests for schema exclusions
* Move exclusion check to should_include_endpoint
* Update docs
* Switch to using `schema = None`
* Test PendingDeprecationWarnings
* Add note to release notes.
* s/deprecated/pending deprecation/
* Add PR link to release notes
* Correct typo in test class name
* Test 'exclude_from_schema' deprecation warning message (#1)
* Correct deprecation warning message
* Initial Refactor Step
* Add descriptor class
* call from generator
* proxy back to generator for implementation.
* Move `get_link` to descriptor
* Move `get_description` to descriptor
* Remove need for generator in get_description
* Move get_path_fields to descriptor
* Move `get_serializer_fields` to descriptor
* Move `get_pagination_fields` to descriptor
* Move `get_filter_fields` to descriptor
* Move `get_encoding` to descriptor.
* Pass just `url` from SchemaGenerator to descriptor
* Make `view` a property
Encapsulates check for a view instance.
* Adjust API Reference docs
* Add `ManualSchema` class
* Refactor to `ViewInspector` plus `AutoSchema`
The interface then is **just** `get_link()`
* Add `manual_fields` kwarg to AutoSchema
* Add schema decorator for FBVs
* Adjust comments
* Docs: Provide full params in example
Ref feedback b52e372f8f (r137254795)
* Add docstring for ViewInstpector.__get__ descriptor method.
Ref https://github.com/encode/django-rest-framework/pull/5354#discussion_r137265022
* Make `schemas` a package.
* Split generators, inspectors, views.
* Adjust imports
* Rename to EndpointEnumerator
* Adjust ManualSchema to take `fields`
… and `description`.
Allows `url` and `action` to remain dynamic
* Add package/module docstrings
* Update get_object() example in permissions.md
I'm a bit confused about the example that's provided in the 'Object level permissions' section. Other examples (e.g. Tutorial 3 - Class Based Views) provided a pk to get_object(). It doesn't seem like this example has any way of identifying a specific object.
Just in case I'm correct, I've prepared this pull request. But if I'm wrong, would it be possible for you to explain the example I modified?
Many Thanks...
* Adjust patch
Sometimes, probably in the upgrade from Django 1.9 to 1.10, a post with
empty content is forbidden by javascript, with the message "Please fill
in this field". Filling the form with '{}' allows an application/json
request to be submitted.
The API call itself works perfectly well with a post with empty content:
the interface shouldn't make assumptions about it.
