When MFR receives an export request where the input and output formats are the same, it should simply return the original file unmodified... unless there's another reason to export the file (i.e. image scaling).
Why
A no-op is a simple operation to support, why not do it?
Acceptance criteria
A PR to support
QA notes
Devs will test this. Dev, please add a list of affected and unaffected file types.
this affects all file types. Any file type may now be exported. The extension of the file must match exactly the extension of the export, or we respond saying we cant export it. (i.e .jpg and .100*100.jpg are not the same, and the 100*100.jpg will trigger a actual file conversion)
Build an MFR export url requesting to export a file of type foo as type foo. This should start a download of the raw file without modification. Exception: image files should respect scaling parameters.
Coverage decreased (-0.2%) to 71.117% when pulling 072c3e08cca190a1b42dc3e8b3abacf031cf78f2 on birdbrained:ft/noop-only into 681a0ce0618d047cc9481b1bd9174b9f7b2d2b1b on CenterForOpenScience:develop.
Ticket
https://openscience.atlassian.net/browse/SVCS-678
Purpose
What
When MFR receives an export request where the input and output formats are the same, it should simply return the original file unmodified... unless there's another reason to export the file (i.e. image scaling).
Why
A no-op is a simple operation to support, why not do it?
Acceptance criteria
A PR to support
QA notes
Devs will test this. Dev, please add a list of affected and unaffected file types.
Build an MFR export url requesting to export a file of type foo as type foo. This should start a download of the raw file without modification. Exception: image files should respect scaling parameters.