Enable derivative download for materials where original derivative file doesn't match current server locations

[elynema]

Description

In #5816, testing revealed that the current code only [seems to] work for instances where the derivativeFile location is pointing back to muskrat itself. Older configurations in this value did not seem to download properly (error after clicking download). If there is not a way to accomplish this given the diversity of underlying data, we may need to hold this functionality out of 7.8 release (or disable it).

Content stored in HCP also cannot be downloaded at this time, but that is not a requirement for this issue since that content can be downloaded with Archiver.

See #5816 for a list of examples from mco-staging that were tested and more details.

Questions

• How to identify HCP content? From the examples, it looks like the derivativeFile value always is s3 or rtmp protocol.
• What about content with a file protocol in derivativeFile, but rtmp protocol in the location field?

Done Looks like

• [ ] Download works for any NFS stored derivative, even if the derivativeFile location points somewhere other than muskrat
• [ ] For content stored in HCP, the Download button does not appear on the Manage Files page.

Examples that worked with current code (and should continue working):

• [ ] NFS - content directly uploaded into MCO - https://mco-staging.dlib.indiana.edu/media_objects/8910kg12m
• [ ] content migrated over from MCO with 7.7 upgrade (NFS) - https://mco-staging.dlib.indiana.edu/media_objects/5x21v3034.json
• [ ] NFS content migrated from MCO: https://mco-staging.dlib.indiana.edu/media_objects/gf06gv30h

Examples that did not work with current code:

• [ ] - NFS - older content that points to old server host name - https://mco-staging.dlib.indiana.edu/media_objects/dz010q26z.json
• [ ] - very old piece of content - https://mco-staging.dlib.indiana.edu/media_objects/b8515n60s
• [ ] - weird edge case: - https://mco-staging.dlib.indiana.edu/media_objects/qj72p820d.json

HCP examples

• [ ] HCP - MDPI content - https://mco-staging.dlib.indiana.edu/media_objects/kw52jh108.json
• [ ] content migrated over from MCO with 7.7 upgrade (HCP) - https://mco-staging.dlib.indiana.edu/media_objects/vx022667z

[elynema]

Potential suggestion from Chris: I wonder if having a configurable method specific to the instance for resolving the path might be the best way to go. Then we could handle lots of cases in messy ways but keep it contained and outside the main codebase.

[elynema]

Need to do some more investigation before we can really give this a story point estimate.

[elynema]

One thing we do for posters: the code tries to locate the actual file, but if it can't, it pulls the streaming URL and downloads some of the streaming file to pull out the thumbnail. Not ideal solution, but could take a similar approach here; would need to make sure that users can't access that.

[elynema]

Start with a configurable method that works for vanilla Avalon. Once that's merged, we can try to adjust code for our local eccentricities.

hls_url attribute contains the path in it. Core config will pull hls_url, and grab just the path. Looking at examples on mco-staging, this seemed to be the most consistent field.

[joncameron]

• [ ] Write a new ticket on the local board for testing with NFS targets and tweaking configuration as needed.