-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43508/
-----------------------------------------------------------
(Updated Feb. 23, 2016, 5:05 p.m.)
Review request for Ambari, Di Li, DIPAYAN BHOWMICK, Jaimin Jetly, Pallav
Kulshreshtha, and Srimanth Gunturi.
Changes
-------
I have attached a new patch "AMBARI-14932_fix2" which retains the changes from
AMBARI-14228 by updating the condition in the controller "file.js" where it
checks for "data.allowed" only if option="browse". No changes are required in
the server-code.
Please provide your feedback on the new fix.
Bugs: AMBARI-14932
https://issues.apache.org/jira/browse/AMBARI-14932
Repository: ambari
Description
-------
Steps to Reproduce:
1. go to "View" - "FILES" - " Create Instance"
2. go to hdfs file view
3. click "download zip" icon
The click doesn't download any file. The REST call returns 200 OK status.
Detailed steps on configuring Views can be found in the link below:
http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf
Diffs
-----
contrib/views/files/src/main/java/org/apache/ambari/view/filebrowser/DownloadService.java
749174a
contrib/views/files/src/main/resources/ui/app/controllers/file.js 88fa5fb
Diff: https://reviews.apache.org/r/43508/diff/
Testing
-------
FIX:
The check for "allowed" in the controller, from the response of
zipByRequestId() ("/zip" API call for downloading zip file) resulted in no
action after clicking the download zip button. This was because there was no
"allowed" paramter in the response of zip download. This "allowed" property was
added in the response of browse() ("/browse" API call for downloading
individual file) to check if the user had permissions for the file or not. This
was verified by opening the file. If that operation didn't throw an error, then
it would mean that the user had the required permissions to download the
individual file. But the fact that the point of execution reaches past the
statement of opening the file verifies that the user has the permission. The
check with "checkperm" and setting the response with "allowed" attribute in the
response is not necessary.
So, for the fix I simply removed the check for "allowed" from the controller
and also removed the check for "checkperm" which sets the "allowed" attribute
in the response.
TESTS:
There are already exisitng tests for DownloadService, so I haven't added any
new ones.
File Attachments (updated)
----------------
AMBARI-14932_fix2
https://reviews.apache.org/media/uploaded/files/2016/02/23/8a296b75-37ed-442e-88cc-70319a7bdda5__AMBARI_14932_Feb23.patch
Thanks,
Keta Patel
