Limit batch download to a certain selection size

[pascalwengerter]

Expected behaviour

For a certain total size of the currently selected files, we should not offer the download button in the frontend.

Background

Technically, this request is a workaround for CERN, who want to disallow downloads on certains paths.
Their proper solution needs backend changes, but until then (and in general), there should be a maximum filesize for archiver/single file download?

[pascalwengerter]

@tbsbdr

• is this wanted?
• should this be configurable?

[tbsbdr]

@pascalwengerter unsure about the discussed status yesterday in the room - is this still needed to unfork cern?

[pascalwengerter]

@pascalwengerter unsure about the discussed status yesterday in the room - is this still needed to unfork cern?

I don't think we'd need feedback today or this issue for the cern-unfork in general, but might be worth adding it to the project in general at a later point? :) your call

[dragotin]

Technically, this request is a workaround for CERN, who want to disallow downloads on certains paths.

Can "paths" be translated to Spaces in this case? It could be a property of a project space if batch download is allowed or not. @micbar: is that doable?

@labkode would that be sufficient?

[kulmann]

@dragotin this issue originally was about preventing users from trying to download an archived version of /eos/user with a few petabytes of data. Not so much about subfolders of a personal space or a project space. Preventing archive downloads per space (who configures that? the space manager?) is a weird thing IMO. It would just annoy people who want to download things by forcing them into downloading each file individually. And forbidding downloads in general is again another story (similar to secure view maybe) - which makes sense again in sharing and per-space config.

I still agree that it's a good idea in general to limit the max size for an archive download to some number. Don't know what's reasonable, but as long as it's configurable for the whole system people should be happy. Eventually you want people to use the desktop client to retrieve larger amounts of data.

[kulmann]

Meanwhile this has been implemented in oCIS / reva. The archiver capability looks like this:

We'll need to implement nice UX for when the selected file sizes are too large.

[pascalwengerter]

@kulmann @tbsbdr what about

• a simple modal announcing that no download will be available for the size/amount of selected files once the limit has been reached?
• showing a disabled "batch download" button with an explanatory hover text/aria-label instead of the normal, working one?
  There's a balance to be struck here between "not too invasive" and "not visible enough" though

[pascalwengerter]

@labkode @diocas @elizavetaRa I know this "still" isn't the exact solution to your problem, but since your idea needs backend adjustments that may take a while and the suggested approach here prevents your users from downloading massive amounts of data should I focus on this as a quick-fix-ish solution?

[labkode]

@pascalwengerter I prefer the showing a disabled "batch download" button with an explanatory hover text/aria-label instead of the normal, working one? as it provides to the user the information that this functionality is not available. The modal implies the user will go and click. @elizavetaRa @diocas your thoughts?

[pascalwengerter]

@pascalwengerter I prefer the showing a disabled "batch download" button with an explanatory hover text/aria-label instead of the normal, working one? as it provides to the user the information that this functionality is not available. The modal implies the user will go and click. @elizavetaRa @diocas your thoughts?

Same, I've opened a draft PR with an initial sketch that shouldn't be too hard to drag across the finish line ✊🏽 great that the archiver now "knows (announces) its limits" also 😄