HUE-8556 [fb] Overuse of trash folder checking.

Review Request #13334 - Created Sept. 12, 2018 and submitted

Jean-Francois Desjeans Gauthier
commit 1049fc1444087e2d7205bbbaef94b6fdb8039b6c
Author: jdesjean <>
Date:   Wed Sep 12 12:05:40 2018 -0700

    HUE-8556 [fb] Overuse of trash folder checking

:100644 100644 4bb472c5a8... c989e88640... M	apps/filebrowser/src/filebrowser/
:100644 100644 e25d918a95... f3f5a71322... M	desktop/libs/hadoop/src/hadoop/

  • 0
  • 0
  • 2
  • 0
  • 2
Description From Last Updated
  1. The goal of the flag is: When do we show the Trash icon and the Move to Trash action (AFAIK if we use the WebHDFS API correctly this is handled).

    In case of encryption zone, the trash is in the Encryption zone itself (should be handled by the API).

    IIRC One issue is that the Trash folder is not created automatically even if the Trash is enabled, so if the user clicks on the Trash icon, we will get an error as the path does not exist.
    ([]) ()

    1 So, when clicking on the Trash icon in FB, could we make sure we create it on the fly or we could send a message that the Trash is empty?

    2 If we are on the encryption zone and click on the Trash icon, right now we would land in the user trash. This might be confusing or not (best would be to do the GETTRASHROOT call like right now so we open the good trash).

    1. (not sure if 1 and 2 are already handled or not)

    2. I tried 1 and it is already handled.
      From my reading of the code, 2 is also already handled.

    3. For 1:
      For 2:

    4. I should add that current implementation was incorrect (e.g. not showing option for trash if no .Trash folder was created in user directory). The only valid option is to check for this configuration.

    5. 1 is

  2. apps/filebrowser/src/filebrowser/ (Diff revision 1)

    nit: can put on one line now

      • Removed several repeated network calls.
  1. Ok!

  2. nit: new line to split core and libs

Review request changed

Status: Closed (submitted)