2.3 drag&drop and aliases incompatibility

2.3 drag&drop and aliases incompatibility

by Joseph Rézeau -
Number of replies: 10
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

From the 2.3 release notes page:

1.- "You can now drag and drop files directly from your desktop straight into file areas! "

2.- "Files can be created as "aliases/shortcuts" of other files. This allows you to, for example, use a single file in your private files area multiple times in all your courses. If you update the original file then all the aliases will automatically update!"

Unfortunately, features 1 and 2 are not compatible. Let me explain.

There are 2 ways to upload a file and we would think that those two ways also apply to the "update" of an original file in e.g. the "My private files" repository.

a) using the file picker: Files / Add / Upload a file and upload the new version of your original file. Then you are warned that "File exists" "A file with that name has already been attached" and prompted to either Overwrite or Rename the original file (or Cancel). Of course, for updating the original file you have to Overwrite it. This works as expected.

b) using the drag & drop new feature : if you try to drag and drop the new version of an already uploaded file, you are not warned that "File exists" and the new version of our original file is automatically renamed (e.g. catimage.jpg is renamed to catimage_2.jpg).

If people agree that this not an "intended feature" but a bugwink I will post a bug report.

Joseph

Average of ratings: -
In reply to Joseph Rézeau

Re: 2.3 drag&drop and aliases incompatibility

by Mark Johnson -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

On a related note, can a user create an alias by drag and drop? Is there a way of dragging a file from one page to another (or the same file on to more than one page), and being given the option to make an alias? 

If not, I'll happily file the bug if there isn't one, just let me know!

In reply to Mark Johnson

Re: 2.3 drag&drop and aliases incompatibility

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Mark, that could be difficult to implement, if you are talking about dragging items between browser windows. You probably wouldn't be able to tell that the content was a file URL instead of a random link dragged off an unrelated website until you dropped it (so during the drag you would have to display the 'drop here' message, only to potentially ignore it when the drop happened).

Apart from that it should be fairly straightforward to recover the file information from the included URL.

Would you be able to clarify exactly where you want to drag the files from? From a currently open file manager form element, from the private files block, or just from arbitrary file links on the Moodle site?
In reply to Davo Smith

Re: 2.3 drag&drop and aliases incompatibility

by Mark Johnson -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Sorry for not being terribly clear, hopefully these mockups should demonstrate the scenarios I'm thinking of (assuming I've correctly understood how d&d currently works):

User drags file 1 into course 1

User drags same file to course 2, dialogue is displayed

In reply to Mark Johnson

Re: 2.3 drag&drop and aliases incompatibility

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

In screen 2, the file does not already exist within the course - a file with the same name already exists within one of the modules within the course. To implement what you are suggesting, you would need to ask each activity / resource to check through all the files it contains and see if it has one that matches the filename just uploaded. Even then, I'm not convinced that is what you actually want to do, as I'm sure that there are many situations that name clashes can happen accidentally and it would be very annoying to continually pop-up a message to let you know (if you really want to replace a file, then click on edit and drag a new file onto the filemanager element on the settings form).

Screenshot 3 doesn't really have a sensible solution either - you are illustrating the dragging and dropping of an activity from one course to another, not dragging a file from one course to another (even if, as you are illustrating, you happen to be dragging a file resource that, in this case, only contains a single file). You might want to trigger an import in that situation, but there is still an issue that you can't, as far as I remember, actually drag activity links from the course page, as the 'activity re-ordering' drag and drop code interferes with the ability to drag links.

In reply to Davo Smith

Re: 2.3 drag&drop and aliases incompatibility

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I don't think this should be based on file name at all.

We should be using file content hash, and it is quite easy to do

SELECT DISTINCT contextid FROM {files} WHERE contenthash = ?

Then see if any of those contexts are in the course.

However, as you say, it is not clear if implementing this makes sense or not.

In reply to Tim Hunt

Re: 2.3 drag&drop and aliases incompatibility

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Surely the point was that someone might want to drag an updated file onto the course and have it (optionally) replace the original (a bit like dragging an updated file onto a file manager)? If this was the case, then the file content hash wouldn't be helpful.

The only real advantages of detecting multiple uploads of the same file, would be to warn users, to avoid possible confusion and to reduce storage usage (which doesn't apply anyway, due to the way Moodle stores files).

In reply to Davo Smith

Re: 2.3 drag&drop and aliases incompatibility

by Mark Johnson -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Tim's suggestion was more along the lines of what I was thinking.

I agree with your first point, but not your second.

I agree that, if you're dropping a file on to a page where the file* already exists, you'd want to check the file name and offer to either update the existing file or create a new copy.

However, I definitely think that detecting a duplicate upload based in the hash on a page where the file doesn't already exist has a usability advantage, as it gives you the opportunity to create a single point of update using aliases if desired.  In my experience, this is the way our users (particularly the less technical ones) tend to expect things to work.

* I'm thinking of what our users understand as a file, i.e. an instance of the File module containing an uploaded file.

In reply to Mark Johnson

Re: 2.3 drag&drop and aliases incompatibility

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Mark,

As Davo says, it's not clear what you want to do and probably not possible to implement anyway.

Joseph