Bug #13454
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
Status: | Verified | Start date: | 12/18/2020 | |
---|---|---|---|---|
Priority: | Medium | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Archivematica integration | |||
Target version: | Release 2.7.0 | |||
Google Code Legacy ID: | Tested version: | |||
Sponsored: | No | Requires documentation: | No |
Description
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.
History
#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'):
https://wiki.archivematica.org/Storage_Service_API
For regular DIP Upload this information comes from the QubitAIP record:
https://github.com/artefactual/atom/blob/2cc4187c0c66980a99f0fc37180c3c616cb79196/plugins/arStorageServicePlugin/modules/arStorageService/actions/extractFileAction.class.php#L104-L105
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:
https://github.com/artefactual-labs/agentarchives/blob/2e316f502d94c1ef09f3954a5e4b1450ee445f35/agentarchives/atom/client.py#L635
https://github.com/artefactual/atom/blob/d1b32f079bf4bf4421f4f9ec8af2ec74f6a0f0d6/plugins/arRestApiPlugin/modules/api/actions/digitalobjectsCreateAction.class.php#L53
...but the AIP file name (required by the AMSS) does not seem to be.
#3 Updated by Steve Breker over 1 year ago
PR for AtoM change:
https://github.com/artefactual/atom/pull/1237
#4 Updated by Steve Breker over 1 year ago
Merged to qa/2.x
#5 Updated by Dan Gillean over 1 year ago
- Status changed from New to QA/Review
#6 Updated by Dan Gillean over 1 year ago
- Assignee changed from Steve Breker to Peter Van Garderen
Peter, Sarah mentioned that you are testing this issue - is this the case?
#7 Updated by Dan Gillean over 1 year ago
- Status changed from QA/Review to Verified
- Assignee deleted (
Peter Van Garderen)
#8 Updated by Redmine Admin over 1 year ago
- Target version changed from Release 2.6.2 to Release 2.6.3
#9 Updated by José Raddaoui Marín about 1 year ago
- Target version changed from Release 2.6.3 to Release 2.7.0