Merge lp://staging/~fgallina/rnr-server/clickpackage-moderation into lp://staging/rnr-server
Status: | Merged |
---|---|
Approved by: | Fabián Ezequiel Gallina |
Approved revision: | 286 |
Merged at revision: | 276 |
Proposed branch: | lp://staging/~fgallina/rnr-server/clickpackage-moderation |
Merge into: | lp://staging/rnr-server |
Prerequisite: | lp://staging/~fgallina/rnr-server/paginated-handler |
Diff against target: |
1018 lines (+793/-34) 9 files modified
src/clickreviews/api/handlers.py (+131/-6) src/clickreviews/api/urls.py (+43/-0) src/clickreviews/forms.py (+55/-1) src/clickreviews/models.py (+4/-6) src/clickreviews/tests/test_forms.py (+182/-3) src/clickreviews/tests/test_handlers.py (+353/-1) src/core/api/pagination.py (+0/-4) src/core/models.py (+4/-13) src/reviewsapp/models.py (+21/-0) |
To merge this branch: | bzr merge lp://staging/~fgallina/rnr-server/clickpackage-moderation |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Fabián Ezequiel Gallina (community) | Approve | ||
James Westby (community) | Approve | ||
Review via email:
|
Commit message
Implementation of moderation endpoints for click packages
All API endpoints require that users have the moderator permissions
and read enpoints support pagination.
For setting a moderation status, a PATCH request is necessary, just
including moderation_text in its data.
Here are API endpoints available for click package moderations, click
package review moderations are omited as the endpoints are exactly the
same, with the exception that the base url path is
/click/
GET /click/
Serves all click package moderations available of any status.
Supports pagination via the page and page_size GET params.
GET /click/
Serves all click package moderations of pending, approved or rejected
status respectively. Supports pagination as well.
GET /click/
Returns a single package moderation instance with pk 1 (or 404 if missing).
GET /click/
Returns a single pending package moderation instance with pk 1 (or 404 if missing).
PATCH /click/
Sets moderation with pk 1 to approved if all validation checks pass.
For the request to work, moderation_text should be included in the
request data (e.g. '{"moderation_
'application/json' as the value for the Content-Type header).
Supported content types are those of Piston: JSON, YAML, XML and
Pickle.
Description of the change
Implementation of moderation endpoints for click packages
All API endpoints require that users have the moderator permissions
and read enpoints support pagination.
For setting a moderation status, a PATCH request is necessary, just
including moderation_text in its data.
Here are API endpoints available for click package moderations, click
package review moderations are omited as the endpoints are exactly the
same, with the exception that the base url path is
/click/
GET /click/
Serves all click package moderations available of any status.
Supports pagination via the page and page_size GET params.
GET /click/
Serves all click package moderations of pending, approved or rejected
status respectively. Supports pagination as well.
GET /click/
Returns a single package moderation instance with pk 1 (or 404 if missing).
GET /click/
Returns a single pending package moderation instance with pk 1 (or 404 if missing).
PATCH /click/
Sets moderation with pk 1 to approved if all validation checks pass.
For the request to work, moderation_text should be included in the
request data (e.g. '{"moderation_
'application/json' as the value for the Content-Type header).
Supported content types are those of Piston: JSON, YAML, XML and
Pickle.
Hi,
Thanks for making the changes, it all looks good now.
The pattern I like for testing when you add a .select_related() is the following.
def test_queries_ dont_scale( self): queries = 6 makeThing( ) assertNumQuerie s(expected_ queries, self.client.get, '/all-things') makeThing( ) assertNumQuerie s(expected_ queries, self.client.get, '/all-things')
expected_
thing = self.factory.
self.
another_thing = self.factory.
self.
This is because for me the test isn't so much about the exact number of queries, ies() or something then using that would be fine.
but about the fact that they don't increase with the number of things. Obviously
it asserts the number of queries too, but if there was a way for the first assertion
to be a getNumberOfQuer
Overall a very nice branch, takes care of a lot of things.
Thanks,
James