Add detail table to resource detail page

[clash99]

For our users with slower connections, it would be good for them to know the file sizes of our resources before they choose to download them. Also any additional information we could give them before downloading would be helpful. I suggest adding a detail table similar to the mock below and making a few adjustments to the page title to match the party detail page. Some fields such as dimension wouldn't be shown for files that weren't images.

I can see us wanting to add file size next to the resource name in other pages on the platform too.

[clash99]

@oliverroick and @amplifi - before I create any mocks for this, can you let me know if this is able to be first-contributor friendly or are there security concerns or other issues I'm not aware of? Thanks!

[amplifi]

@clash No issues here 👍

[aadityasg]

@clash99 @amplifi Is there any pending discussion on this issue? Or we intend to display download size next to various options on export page before user actually downloads the file?

[clash99]

@aadityasg Sorry, not ready for this one yet.

[clash99]

@aadityasg That would be a great idea too but this task is for individual resources, not the downloading of multiple. I'm hoping to put more requirements for this together today. I will also pass on this idea to our project owner since I believe its a good idea. Thanks!

@dpalomino - see note above about including file sizes when downloading project data.

[clash99]

I've updated the title and description of this task to better match what we are trying to do.

@dpalomino - I'm marking this first-contributor friendly. Please remove if you disagree.

[dpalomino]

Thanks @clash99! Yes I agree.

I think we should show the size of "Resources" and "All data" in Download project data:

And in the details of each individual resources (probably a line before "Added on..."):

[clash99]

It sounds good but I'm not sure if we know the file sizes ahead of time for the data download options. I think we should add anything outside of the resource detail page in another task for investigation. Sound reasonable @dpalomino?

[seav]

I would strongly advise against including the file size for the project data download feature. To get this information, we would need to actually generate the files to be downloaded for all options, potentially wasting CPU cycles and S3 accesses for resources in case the user decides to cancel.

[clash99]

I was thinking that might be the case @seav. Thanks for clarifying.

[dpalomino]

Thanks for the heads-up @seav, I wasn't aware of this complication. Let's then go with the original proposal for the individual resources only (unless we can find out a workaround to estimate an approximate size for downloading all the resources).

[EkaterinaSemenova]

As far as I understand, to implement this feature we need to add additional properties (e.g. file_size, image_dimensions etc.) to either Resource model or underlying S3File. Which way sounds more reasonable for you?

[khantaalaman]

@clash99 @seav A PR has been submitted for this issue. Please review whenever possible.

Thanks!

[amplifi]

@clash99 @dpalomino @seav It would actually be trivial to obtain reasonable file size estimates for all resources and all project data downloads. S3 maintains metadata including file size and type, so files shouldn't need to be downloaded to obtain a size estimate. However, this would be inefficiently handled under the current platform code and should be included in the async I/O work.

[dpalomino]

Thanks a lot @amplifi. It'd be great if we can include it in the async i/o yes (#490).