| Age | Commit message (Collapse) | Author | 
 | 
 | 
 | 
 | 
 | 
Bugfix/1398
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
override_method should substitute action
 | 
 | 
reset stored credentials when call client.logout()
 | 
 | 
Refactor login template to extend base.
 | 
 | 
Leave status responsibility to parent class
 | 
 | 
Allow use of native migrations in 1.7 — Take 2
 | 
 | 
Copy filter_backends class attribute before returning it.
 | 
 | 
 | 
 | 
 | 
 | 
Issue #1707: Add documentation to api-docs.viewsets
 | 
 | 
Updated documentation for urls.py
 | 
 | 
 | 
 | 
A view's action is dependent on the request method. When overriding the method (e.g. to generate a form for a POST request on a GET call to the browseable API), the action should be updated as well. Otherwise, viewset functions may be in a weird limbo state where a 'list' action has a POST method.
 | 
 | 
 | 
 | 
When a ValueError is raised in ModelSerializer.restore_object, the error
is set to a one-element list, rather than a bare string.
 | 
 | 
 | 
 | 
I made a small change in the order of the documentation for urls.py. I feel it helps make it clear which lines you should add to the root settings.
 | 
 | 
I added a brief description of how you could specify a different query parameter for the OrderingFilter.
 | 
 | 
These duplicate attributes are ignored by at least Firefox and Chrome, so this change has no effect on the style
 | 
 | 
Django's `HttpResponse` class checks for the `status` param when it's
initialized, if it's `None` it uses the class attribute
`status_code` and thanks to that we can do things like:
```
class BadRequest(HttpResponse):
    status_code = 400
```
Now, that doesn't work when inheriting from rest-framework's `Response`:
```
class BadRequest(rest_framework.response.Response):
    status_code = 400  # Bad, it's always ignored
```
Because a default status of `200` is being specified in
`rest_framework.response.Response`. I think is more Django-friendly to
just leave that status default value to `None` and leave the
responsibility of choosing its value to the parent class: `HttpResponse`.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
to the `queryset` property, `get_queryset()`, and do generic-views.md; remove
changes to the viewsets.md documentation from my last commit.
 | 
 | 
 | 
 | 
 | 
 | 
Conflicts:
	rest_framework/fields.py
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
Conflicts:
	docs/topics/release-notes.md
 | 
 | 
`SOUTH_MIGRATION_MODULES` setting from `rest_framework.settings`
 | 
 | 
 | 
 | 
Conflicts:
	.travis.yml
	docs/api-guide/viewsets.md
	rest_framework/serializers.py
	rest_framework/throttling.py
	tests/test_generics.py
	tests/test_serializers.py
	tox.ini
 | 
 | 
 | 
 | 
While experimenting with extending DRF, I found that the login page
1) had no title, and 2) duplicated <head> info from base.html.
This change adds a new {% block body %} to the base.html template
which allows override of the entire html <body>. login_base.html
has its duplicated head info stripped, and now extends base.html
to share common html <head> templating.
As part of this change, pretify.css is unnecessarily added to
login_base.html.  If this is deemed a problem, it will be easy to
block that css out, and have login_base.html override the block.
Ideally, I would have liked to create a new api_base.html that extends
base.html, move the api specific logic into that template, and leave
base.html content agnostic, to truely be a unifying base for all DRF
pages.  But this change would break current apps that override
api.html and expect base.html to be the immediate super template. :/
This change is benificial because it:
 - removes duplication of header declarations (mostly css includes)
 - adds a html title to the login page
 - standardizes html header info across all DRF pages
Docs are updated to reflect the new structure.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
If `content_type` is specified in the `APIRequestFactory`, always
include it in the request, even if data is empty.
 | 
 | 
 | 
 | 
 |