✨ Enable multiple file uploads

[cp2004]

What does this PR do and why is it necessary?

This PR has the necessary code changes to allow multiple file uploads to work in the UI with no strange side effects, and making sure that the 'file exists' dialogs work correctly. It fixes issue #4300 and aims to address the comments in #1868 as well.

Some of the stuff it does:

• Allows to select multiple files to upload
• Only refreshes the file list at the end of batch uploading
• Queues the 'File already exists' dialogs
• Displays the filename in any errors that are shown, so if 1 file out of 5 fails for example, you can see what failed.
• All the files are highlighted yellow, but only scrolling to the position of the last file to be uploaded on stop.
  • ~~This is the only outstanding TODO - I can't get it to scroll to the correct position currently. It will scroll but to completely the wrong place 🙈~~
    • ~~I'll try and sort this out next week.~~ Done

How was it tested? How can it be tested by the reviewer?

I have a small folder of 8 files of varying file sizes that I have been using to test this. Some things that can be done:

• Upload one file (gcode, STL and name collision) (check everything still works as before 🙂)
• Select multiple files from the 'Upload' button
• Drag and drop multiple files
• Uploading multiple STL files (Probably requires a slicer plugin - I used the Slic3r with my PrusaSlicer install)
• Uploading a mix of gcode/STLs
• Uploading a mix of files that collide and files that can just be uploaded
• To demo the error handling, I simulated an error in the API by adding this to the code:

  def uploadGcodeFile(target):
      from random import randint
      if randint(1, 5) % 2 == 0:
          abort(500, "simulated error")
  

Any background context you want to provide?

See issues

I have dug quite deep into how the jquery file upload works, the documentation wiki is good https://github.com/blueimp/jQuery-File-Upload/wiki/Options

What are the relevant tickets if any?

#4300 #1868

Screenshots & Videos

I may record a video, maybe not. It's not very interesting!

Further notes

I am not completely sure that the recursive way that file collision dialogs are handled is necessarily the 'best', but it seems to work well. When the dialog closes, the next one is called.

When writing new code, I used modern JavaScript features to make it less verbose. I will have to check on the browser compatibility, but it's passed the ESLint checks.

I'll carry on testing, I would like to test this on my Pi or with a simulated slow network connection to actually watch the progress bar works well. I think it does but it does move quite quickly when just uploading to localhost on my SSD!

[jneilliii]

Replaces https://plugins.octoprint.org/plugins/MultipleUpload/, should we delist the plugin once merged and released?

[cp2004]

I would say yes - tagging @eyal0 to notify, I think there would not be a need to maintain that plugin in the repository anymore.

[cp2004]

Note that when testing it with some small files and some large files (on a Pi with an SD card), there is some odd refreshing of the file list with file analysis - if you upload a 200kb file and a 60mb one on a slow connection for example, OctoPrint can finish analysing the small file, so the list is refreshed mid-upload. These requests would end up being made anyway, so the files just pop up in the list mid way through.

[eyal0]

As an alternative to delisting it, we could also just mark the maximum version for it. That might be appropriate because we might have users that want multiupload but haven't yet upgraded their printers to the latest OctoPrint. Something like:

# Any additional requirements besides OctoPrint should be listed here
plugin_requires = ["OctoPrint<2.12345"]

Added to setup.py.

[jneilliii]

Good point @eyal0, can also do that with the plugin listing's md file in compatibility section.

[cp2004]

Hmm, adding it to plugin_requires would downgrade the OctoPrint version installed to whatever satisfies the constraint if someone tried to install it, which might not be desired behaviour - rather than blocking installation. Putting the compatibility information into the plugin's listing on https://plugins.octoprint.org would mean it would show as 'incompatible' and not be able to be installed through selecting in the plugin manager, and would be a better solution in my opinion.

[eyal0]

This file? https://github.com/eyal0/plugins.octoprint.org/blob/gh-pages/_plugins/MultipleUpload.md

What change do I need to make? Or, one of you can push a PR...?

[jneilliii]

I can assist with the modifications when the time comes. It's basically adding PEP440 values to the compatibility.octoprint section of the template. My assumption is something like this would work.

compatibility:
  octoprint:
  - < 1.9.0

or maybe

compatibility:
  octoprint: < 1.9.0

will have to do some testing....

[cp2004]

• This is the only outstanding TODO - I can't get it to scroll to the correct position currently. It will scroll but to completely the wrong place 🙈
  • I'll try and sort this out next week.

I have pushed a fix that means that the correct code now runs. It scrolls mostly towards the correct file, although not perfectly in line each time. I am not sure if that is something I impacted however, so maybe I will check that. Otherwise I'm happy this is done.

[foosel]

FYI, looking at this is on my TODO list, but I'm currently fully focused on 1.8.3.

[foosel]

Now all that remains are merge conflicts 🙈 On it.