Feature #13351: Download AIP and AIP files from AtoM UI
Problem: Archivematica "Download File" link does not work if metadata-only DIP upload was used
|Target version:||Release 2.7.0|
|Google Code Legacy ID:||Tested version:|
For regular DIP uploads, Archivematica uploads a AIP METS file which AtoM parses to find the relative path for the files in the AIP. It uses this value to create the Archivematica Storage Service request for the file when "Download File' link is clicked. See https://www.accesstomemory.org/en/docs/2.7/user-manual/import-export/upload-digital-object/#digital-object-preservation
However, for metadata-only DIP uploads to AtoM, Archivematica uses the AtoM agentarchives library to pass AIP metadata instead of uploading a METS file. It does not include the file's relative path value. So when an AtoM user clicks on a "Download File" link for a metadata-only DIP upload the user will receive a "400 Missing parameter: relativepath" error.
This is being addressed for Archivematica, see: https://github.com/archivematica/Issues/issues/1334
Once Archivematica is passing this value correctly, AtoM needs to be updated to save the file relative path correctly so that it can be retrieved to generate the correct request parameter for the "Download File" link.
#1 Updated by Douglas Cerna over 1 year ago
AtoM needs to be updated to save the file relative path correctly
One thing to consider is that currently the "Download File" link verifies that a QubitAip instance exists. This is the case only in the regular DIP upload workflow, but not when the metadata-only DIP upload creates the digital objects through the API.
#2 Updated by Steve Breker over 1 year ago
The AM Storage Service API extract_file endpoint requires both the AIP UUID and the AIP filename (Search for 'extract_file'):
For regular DIP Upload this information comes from the QubitAIP record:
For metadata-only DIP upload, this QubitAip record is not available.
- Can the storage service extract_file endpoint be modified so that it only requires the file UUID to find and extract the file from the correct AIP? Or require only the file and AIP UUIDs (minus the AIP file name)?
- Is this data stored elsewhere in AtoM that it could be looked up? (AIP UUID seems to be, but AIP file name does not)
If not we will need to modify AtoM's API and the agentarchives/atom/client.py to pass this info in and store it with the digital object (perhaps as a property like with the UUID). In the AtoM file extractFileAction.class.php these properties could be used if the QubitAip is not available.
It looks like the AIPUUID is already being passed to AtoM and stored as a property attached to the digital object record:
...but the AIP file name (required by the AMSS) does not seem to be.