Drag 'n Drop Inline Images Backend - WebAPI
Review Request #6617 — Created Nov. 21, 2014 and submitted
Part of a set of changes to add support for dragging and dropping images into the markdown editor.
- Creating a Web API for user file attachments, UserFileAttachment resource.
- UserFileAttachment resource can be accessed at /api/users/<username>/file-attachments/<id>/
- Users can only get/modify/delete their own UserFileAttachments. Superusers can get/modify any.
- UserFileAttachments can be created (using POST) without an associated file, in this case the database entry will be created, and the view will return a 404.
- UserFileAttachments can be modified (using PUT) to include a file. This can only be done to UserFileAttachments that do not already have an asosciated file.
- When deleting a UserFileAttachment, the associated file is also deleted.
Also did some refactoring of the base_file_attachment Web API resource so that it could be extended by both user_file_attachment and review_request_file_attachment resources.
All unit tests pass after making the changes.
Extensive manual testing of UserFileAttachment Web API resource using Postman REST client:
- Testing each method (GET/POST/PUT/DELETE) for UserFileAttachment as a regular user and superuser.
- Testing local_site functionalityAdded unit tests around the new UserFileAttachment WebAPI Resource.
Description | From | Last Updated |
---|---|---|
These two statements can be combined. |
david | |
You can remove the "that is" part. |
chipx86 | |
This isn't your fault, but this is no longer true, given that the thumbnail can also be updated. Can you … |
chipx86 | |
We use resources everywhere else. We should keep consistent with that. |
chipx86 | |
This will appear in the published docs, so we should flesh this out a bit more, make it easier to … |
chipx86 | |
This can be one statement. |
chipx86 | |
user_file_attachment is local to this file, so no need to access it through something else. |
chipx86 | |
We have all the info we need at the time we're building the filter, so let's just do this inside … |
chipx86 | |
The summary must fit on a single line. You can try: Returns information on a user's file attachment. |
chipx86 | |
Both of these are saying the same thing. |
chipx86 | |
This isn't strictly true. It's not expected, but rather, optional. Maybe: "If file data is provided, then it is expected … |
chipx86 | |
Some of this can use the has_list_access_permissions(). |
chipx86 | |
I don't think you need to copy the dictionary. |
chipx86 | |
This can be: if 'path' in request.FILES ...: |
chipx86 | |
Shouldn't need to copy. |
chipx86 | |
""" on the next line. (Note the above comment about how summaries must be on a single line? Unit tests … |
chipx86 | |
No period at the end. |
chipx86 | |
Why does this one have a _ prefix, but create_user_file_attachment does not? Why is create_base_file_attachment "private"? |
mike_conley | |
Nit - local_site_name is the first item in the rest of these url getters - might as well stick with … |
mike_conley |
-
Looks good. A few things, mostly having to do with docs, and a few ways to simplify some statements.
-
-
This isn't your fault, but this is no longer true, given that the thumbnail can also be updated. Can you rewrite this part of the docstring to explain that both the caption and the file attachment's thumbnail can be updated?
-
-
This will appear in the published docs, so we should flesh this out a bit more, make it easier to read.
How about:
The file attachment is not tied to any particular review request, and instead is owned by a user for usage in Markdown-formatted text. The file contents are optional when first creating a file attachment. This is to allow a caller to create the attachment and get the resulting URL for embedding in a text field. The file's contents can then be added separately (and only once) in a PUT request.
-
-
We have all the info we need at the time we're building the filter, so let's just do this inside the
filter()
call:return self.model.objects.filter(user=user, local_site=local_site)
-
The summary must fit on a single line. You can try:
Returns information on a user's file attachment.
-
-
This isn't strictly true. It's not expected, but rather, optional. Maybe:
"If file data is provided, then it is expected that the data will be encoded as multipart/form-data. ..."
-
-
-
-
-
"""
on the next line.(Note the above comment about how summaries must be on a single line? Unit tests are the one exception.)
-
- Change Summary:
-
Review request changes. Moving the has_list_access_permission() checks into the get_list() method so that we can return a different result depending on what fails.
- Diff:
-
Revision 2 (+845 -281)
-
Tool: PEP8 Style Checker Processed Files: reviewboard/testing/testcase.py reviewboard/webapi/resources/base_file_attachment.py reviewboard/webapi/resources/draft_file_attachment.py reviewboard/webapi/resources/diff_file_attachment.py reviewboard/webapi/errors.py reviewboard/webapi/resources/file_attachment.py reviewboard/webapi/resources/base_review_request_file_attachment.py reviewboard/webapi/tests/mimetypes.py reviewboard/webapi/resources/user.py reviewboard/webapi/tests/test_user_file_attachment.py reviewboard/webapi/tests/urls.py reviewboard/webapi/resources/user_file_attachment.py Ignored Files: docs/manual/webapi/2.0/errors/229-file-already-exists.rst docs/manual/webapi/2.0/errors/index.rst Tool: Pyflakes Processed Files: reviewboard/testing/testcase.py reviewboard/webapi/resources/base_file_attachment.py reviewboard/webapi/resources/draft_file_attachment.py reviewboard/webapi/resources/diff_file_attachment.py reviewboard/webapi/errors.py reviewboard/webapi/resources/file_attachment.py reviewboard/webapi/resources/base_review_request_file_attachment.py reviewboard/webapi/tests/mimetypes.py reviewboard/webapi/resources/user.py reviewboard/webapi/tests/test_user_file_attachment.py reviewboard/webapi/tests/urls.py reviewboard/webapi/resources/user_file_attachment.py Ignored Files: docs/manual/webapi/2.0/errors/229-file-already-exists.rst docs/manual/webapi/2.0/errors/index.rst
-
This looks good to me - but you might want another mentor to kick the tires as well.
-
Why does this one have a _ prefix, but create_user_file_attachment does not? Why is create_base_file_attachment "private"?
-
Nit - local_site_name is the first item in the rest of these url getters - might as well stick with the pattern. Same below.
- Diff:
-
Revision 3 (+845 -281)
-
Tool: PEP8 Style Checker Processed Files: reviewboard/testing/testcase.py reviewboard/webapi/resources/base_file_attachment.py reviewboard/webapi/resources/draft_file_attachment.py reviewboard/webapi/resources/diff_file_attachment.py reviewboard/webapi/errors.py reviewboard/webapi/resources/file_attachment.py reviewboard/webapi/resources/base_review_request_file_attachment.py reviewboard/webapi/tests/mimetypes.py reviewboard/webapi/resources/user.py reviewboard/webapi/tests/test_user_file_attachment.py reviewboard/webapi/tests/urls.py reviewboard/webapi/resources/user_file_attachment.py Ignored Files: docs/manual/webapi/2.0/errors/229-file-already-exists.rst docs/manual/webapi/2.0/errors/index.rst Tool: Pyflakes Processed Files: reviewboard/testing/testcase.py reviewboard/webapi/resources/base_file_attachment.py reviewboard/webapi/resources/draft_file_attachment.py reviewboard/webapi/resources/diff_file_attachment.py reviewboard/webapi/errors.py reviewboard/webapi/resources/file_attachment.py reviewboard/webapi/resources/base_review_request_file_attachment.py reviewboard/webapi/tests/mimetypes.py reviewboard/webapi/resources/user.py reviewboard/webapi/tests/test_user_file_attachment.py reviewboard/webapi/tests/urls.py reviewboard/webapi/resources/user_file_attachment.py Ignored Files: docs/manual/webapi/2.0/errors/229-file-already-exists.rst docs/manual/webapi/2.0/errors/index.rst