Official drag and drop support

[oparoz]

Solution for #405, replaces #519

• You can drag images and albums to any album or the breadcrumb
• If successful, the photowall is redrawn
• If you're not allowed to make the change, elements go back to their initial position

Possible improvements

• Drop targets could be nicer Done
• Dragged albums maybe need a border? After extensive use, I don't think so

Screencasts

http://screencast-o-matic.com/watch/cDnl0rhWt7

Screenshot

Test plan

Name at least one file and one folder with numbers only

As a logged-in user:

• Drag a file to a folder and drop it
• Drag a file to a breadcrumb and drop it
• Drag a folder to another folder and drop it
• Drag a folder to a breadcrumb and drop it
• Make sure sometimes the number folder is the target and sometimes the dragged object
• Test on as many browsers as you can. Some browsers don't handle authorization the same way

Do the same on the public side, but make sure you've added the "editing" permission to the link.

Caveats

Read the FAQ in #405

TODO

• Create our own instance of Files.Client so that we can pick the URL to use

---

@jancborchardt @jospoortvliet @setnes @deMattin @arkascha @elpraga @sualko @Bugsbane @mmattel
@karlitschek @LukasReschke @tahaalibra @viraj96 @imjalpreet @mbtamuli @rahulgoyal030

[mention-bot]

By analyzing the blame information on this pull request, we identified @raghunayyar, @jancborchardt and @imjalpreet to be potential reviewers

[oparoz]

It's ready to review again. Test plan has been updated.
@jancborchardt - Would be good to get your go ahead regarding the dropzones

[mbtamuli]

@oparoz All the tests successfully passed! 👍
Just one problem on the Gallery side.

Logged In

• The Dropzones are properly marked.
• Numbered files and Folders can be dragged and dropped.
• Drag and Drop to breadcrumbs are working.

Public

• From the Gallery side, there was no option to add the "editing" permission to the link. So, no drag and drop. @tahaalibra @imjalpreet @viraj96 Can you confirm?

Tested on -

• Chrome v49/Ubuntu15.04
• Firefox v44/Ubuntu15.04

Two other warnings came up, though maybe not due to this PR.

• Deprecation warning: tipsy is deprecated. Use tooltip instead.
• When I click the share link, the first time after loading the page, only on the Gallery side this warning is logged.
  Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience.

[imjalpreet]

@mbtamuli Yeah, you are right. Right now, there is no option to give editing permission to the link from the gallery side. I am working on that Issue ( #565 ).

[oparoz]

Thanks @mbtamuli . The deprecation warning comes from core and the synchronous XMLHttpRequest warning is generated by the imported share class. It waits on getting the shares before building the UI. That could be fixed by using a spinner and dynamic resizing like in the infobox.

[tahaalibra]

tested on various conditions...working fine...only thing is that no option editing permission and also i can drag and drop files/folder in public view....it fails but i think it would be better to remove the option of drag and drop in public view( when editing permission is not given )

[oparoz]

@tahaalibra - Permission checking on the public side shouldn't be too hard to implement for anybody once this is merged :)