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

Added by Peter Van Garderen over 1 year ago. Updated about 1 year ago.

Status:VerifiedStart date:12/18/2020
Priority:MediumDue date:
Assignee:-% Done:


Category:Archivematica integration
Target version:Release 2.7.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:No


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.

#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

Also available in: Atom PDF