Revamp content file mgt

[akolson]

Summary

This pr revamps tthe content file management UI as described in the figma designs. It also reorders the files display (although this is short-lived based on the next point). Lastly, it prevents uploading of multiple files to document resources. Users with existing multiple uploads will continue to work unaffected, however when they try to remove any of the uploads, they will be presented with a warning, as removing them means they can't add them back. This change means that no more multiple file types can be uploaded for a single resource.

Before:

After:
Old resources with more than one file uploaded;

New resources uploaded;

References

Closes #4840

Reviewer guidance

• Upload a file to a particular folder in a channel
• Edit the channel
• Add a different type of the file by clicking the "Select file" link
• Use the horizontal menu options to replace, remove and download the attached files
• Use keyboard navigation to perform the same actions above
• Observe the UI changes. They should match the design spec

Note:
While running on your local, you might encounter this compile error particularly when interacting with uploaded epub files. Refreshing your browser should resolve the issue temporarily.

[AllanOXDi]

@akolson Great work here. I just left a few comments

[bjester]

Just checking in: I recall you doing some research on files. Are there more changes coming or should I finalize my review?

[akolson]

@bjester, We need some more feedback on UX

[akolson]

For additional context, see this on implementation decisions.

@bjester @rtibbles this is ready for review whenever you have a moment. Thanks

[bjester]

Primary requested change is the download behavior. Please note, the mentioned approach won't work correctly in development because there's a redirect involved

[bjester]

Could we have the download option initiate a download? For PDFs this will likely just open it in a tab, meaning actually downloading it isn't a simple click of this option. Here's an example of an anchor, using download and the original file name, if applicable.

[bjester]

This else branch confuses me a bit. If there's only one file, we delete the file without approval?

[akolson]

@bjester yes, correct. The approval is only for removal of the extra files. Also, based on the current logic, a user is unable to remove a single file, they can only replace or download it, so I think that should cover for cases where a user tries to remove a singly uploaded file.

[bjester]

That really seems backwards to me. If the user removes the last remaining file, then the node becomes incomplete. Therefore it would seem to make sense that it would confirm the deletion of a sole file. The link you shared is a reference to your new /changed code. The existing logic appears to allow removal when there are more than one file, so in that sense, it was most defensive when there was only one file, whereas your logic is defensive (requiring approval) when there are more than one and very lax with one file.

[akolson]

Ahh I get your point! The current implementation doesn't allow removal of single files as the delete option isn't displayed in these instances.

Maybe a more general question would be, do we want users deleting single files? If so, then it makes total sense to add another approval dialog (different from the approval for users that are removing extra files that we are moving away from) to warn users of the implications?

[bjester]

Okay so it seems worthwhile to me to align this logic with that. In other words, have it check if file could be removed and if not, do nothing. As it's written, I feel it's confusing considering this behavior and aforementioned pathway

[bjester]

Seems pretty stable now. Thanks for handling this rabbit hole of a feature, @akolson !