-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Respect archiver limits on BatchAction download #9055
Conversation
e00649a
to
b562d5b
Compare
|
||
const selectedFilesAmount = resources.length | ||
|
||
// TODO: selectedFilesSize doesn't traverse into folders, so currently limited to directly selected resources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kulmann I don't guess there's an easy way to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get your TODO comment. 🙈
- We can check the accumulated size of the selected files and folders against the archiver capability. A folder size always reflects the size of all the children. Tree size aggregation is properly happening backend side. That's what's happening in the reduce statement below and seems to be correct.
- We can't check the accumulated number of files in the selection (because you would need a propfind with depth infinity for that). That's what you did in the line above and is incomplete with just checking the number of selected resources. You only count the number of selected resources while you would need to count the number of all children in the full tree of the selection.
To be honest I would just not look at the number of files. Doing the file size check already helps and is by far the more important check I think.
packages/web-app-files/src/composables/actions/files/useFileActionsDownloadArchive.ts
Show resolved
Hide resolved
b562d5b
to
a100463
Compare
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/66/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/56/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/58/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/53/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/52/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/55/1 |
Results for acceptance oCIS https://drone.owncloud.com/owncloud/web/35735/54/1 |
} | ||
|
||
const selectedFilesAmount = resources.length | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we early return here, so we don't need to fire the accumulator if the limit is already reached ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely, good idea :)
@@ -17,6 +17,8 @@ export interface ArchiverCapability { | |||
formats: string[] | |||
// eslint-disable-next-line camelcase | |||
archiver_url: string | |||
max_num_files: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are those strings ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just using what oCIS/reva provide on my recently pulled docker image ;) see https://github.com/cs3org/reva/blob/2be8a61879b22823c852757497c81f2d544f6f9d/internal/http/services/owncloud/ocs/data/capabilities.go#L114
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we parse them beforehand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this only reflects the raw capabilities coming from the backend. Parsing makes sense in the capability composables though.
@@ -68,6 +90,12 @@ export const useFileActionsDownloadArchive = ({ store }: { store?: Store<any> } | |||
label: () => { | |||
return $gettext('Download') | |||
}, | |||
disabledTooltip: ({ resources }) => { | |||
return archiverLimitsExceeded(resources) | |||
? $gettext('Unable to download that many files at once') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open for suggestions on the final text here btw 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about something like The selection exceeds the allowed archive size (max. xyz MB)
? We should let the user know what limits they are working against. Also wouldn't mention the number of files here since we can't check that.
By the way, I believe that the backend behaviour is faulty and should not offer an archive file for download at all if it's incomplete. What's your take on that? If same we should open an issue in ocis / reva.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the average non-tech user knows how to parse allowed archive size
, but let's roll with it since feedback can easily be implemented at a later point
@@ -0,0 +1,8 @@ | |||
Enhancement: Respect archiver limits | |||
|
|||
The archiver service can now announce a limit for both the amount of resources and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The archiver service can now announce a limit for both the amount of resources and | |
The archiver service can now announce a limit for both the number and |
|
||
const selectedFilesAmount = resources.length | ||
|
||
// TODO: selectedFilesSize doesn't traverse into folders, so currently limited to directly selected resources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get your TODO comment. 🙈
- We can check the accumulated size of the selected files and folders against the archiver capability. A folder size always reflects the size of all the children. Tree size aggregation is properly happening backend side. That's what's happening in the reduce statement below and seems to be correct.
- We can't check the accumulated number of files in the selection (because you would need a propfind with depth infinity for that). That's what you did in the line above and is incomplete with just checking the number of selected resources. You only count the number of selected resources while you would need to count the number of all children in the full tree of the selection.
To be honest I would just not look at the number of files. Doing the file size check already helps and is by far the more important check I think.
const selectedFilesSize = resources.reduce( | ||
(accumulator, currentValue) => | ||
accumulator + | ||
(typeof currentValue.size === 'string' ? parseInt(currentValue.size) : currentValue.size), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(typeof currentValue.size === 'string' ? parseInt(currentValue.size) : currentValue.size), | |
parseInt(`${currentValue.size}`), |
@@ -59,6 +59,28 @@ export const useFileActionsDownloadArchive = ({ store }: { store?: Store<any> } | |||
}) | |||
} | |||
|
|||
const archiverLimitsExceeded = (resources: Resource[]) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const archiverLimitsExceeded = (resources: Resource[]) => { | |
const areArchiverLimitsExceeded = (resources: Resource[]) => { |
@@ -68,6 +90,12 @@ export const useFileActionsDownloadArchive = ({ store }: { store?: Store<any> } | |||
label: () => { | |||
return $gettext('Download') | |||
}, | |||
disabledTooltip: ({ resources }) => { | |||
return archiverLimitsExceeded(resources) | |||
? $gettext('Unable to download that many files at once') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about something like The selection exceeds the allowed archive size (max. xyz MB)
? We should let the user know what limits they are working against. Also wouldn't mention the number of files here since we can't check that.
By the way, I believe that the backend behaviour is faulty and should not offer an archive file for download at all if it's incomplete. What's your take on that? If same we should open an issue in ocis / reva.
a100463
to
950f2a8
Compare
SonarCloud Quality Gate failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it 🚀
for the record, easier to test if one decreases the max file size allowed by the archiver. E.g. as follows:
|
Related Issue
Types of changes
Checklist:
Open tasks: