Bug #5786

Archival description with item-level digital objects don't Roundtrip EAD

Added by Jessica Bushey over 8 years ago. Updated over 8 years ago.

Status:VerifiedStart date:10/12/2013
Priority:HighDue date:
Assignee:José Raddaoui Marín% Done:


Target version:Release 1.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


1. create archival description fonds level with series and items
2. attach digital objects to all items
3. export fonds level description EAD (file attached)
4. delete entire description
5. import EAD
6. fonds and series only, no items, no digital objects imported

expected result
everything imports successfully

cape-town-cricket-club;ead.xml Magnifier (8.19 KB) Jessica Bushey, 10/12/2013 02:54 PM

fivers-collection-of-bunnies;ead.xml Magnifier - sample ead used for roundtripping (8.28 KB) Dan Gillean, 10/30/2013 02:32 PM

error-import.png - screenshot of error message page after import (32 KB) Dan Gillean, 10/30/2013 02:40 PM

import_result.png (53.6 KB) José Raddaoui Marín, 10/31/2013 04:59 AM

imported_descriptions.png (75.1 KB) José Raddaoui Marín, 10/31/2013 04:59 AM

Related issues

Related to Access to Memory (AtoM) - Bug #5788: After XML import screen stays on import Verified 10/12/2013


#1 Updated by José Raddaoui Marín over 8 years ago

  • Target version changed from Release 2.1.0 to Release 1.4.0

#2 Updated by David Juhasz over 8 years ago

The desired functionality here is that the export file includes a <dao> element that links to the digital object in the source system. On import into the destination AtoM system, the digital object should be remotely linked to the digital file in the source system, the digital object should not be imported into the destination system.

This may cause some confusion if you are testing import/export using the same instance of AtoM as the source and destination.

#3 Updated by José Raddaoui Marín over 8 years ago

  • Status changed from New to QA/Review
  • % Done changed from 0 to 100

Hi Jessica an David,

That was the issue, we were throwing an exception when there is a problem fetching an external digital object (deleted all in the point 4). This was breaking the import from that point so the remaining items were ignored. And, as I said in ^^ those errors weren't visible.

Doesn't seem like a good idea breaking the whole process for that, so I've catched the exception and showed it as a warning after the import process has finished.

Hope that's okay.

#4 Updated by David Juhasz over 8 years ago

Catching the error and reporting it after import is a good solution. Thanks Radda.

#5 Updated by Dan Gillean over 8 years ago

I'm not sure that this is yet a solution.

I've created a test collection, "Fiver's collection of bunnies. It has 2 series: Real bunnies (photographs) and Fake bunnies (images, cartoons, etc.). All real bunny series items were linked to external digital objects on the web. All Fake bunny series items were linked to uploaded images.

First, the error message referenced above appears, but there is no indication that the collection was imported anyway, and no way to view the results (no view archival description button). Because it says error with no option to view, most users will assume the file did not upload. One must search AtoM to find out if the files actually imported (they did... mostly). I don't think this ambiguity is something that we should maintain. See attached screenshot.

Examining the results
the "Real bunnies" series imported correctly - all item-level records appeared, including even their digital objects - so AtoM has no problem fetching external digital objects on the web and linking them with an import

The "Fake bunnies" series did not import any item-level descriptions. It makes sense to me that AtoM cannot fetch copies of the digital objects if they are not available in AtoM or online - but it seems to me that the item-level files should import without the digital objects linked, and the error message about fetching them delivered (with a clear indication that something was imported, and a link to view the description).

As such, the disappearance of the item-level descriptions still seems like a major problem to me.

Interestingly, while I created and exported the file from 2.x, when I tried to import it into 1.x, I got a blank white screen. Even using the debug toolbar I couldn't get an error message.

#6 Updated by David Juhasz over 8 years ago

Agreed, if the <dao> link doesn't resolve to a valid resource, the item level descriptive data should still be imported. Radda, is this possible to implement with a try/catch block specific to the <dao> import code?

#7 Updated by José Raddaoui Marín over 8 years ago

Hi guys,

That's exactly what I did David, I had to pass the errors array as a reference to the information object class, where the fetching is made, to get those erros in the importSuccess (I've changed all calls to that method too, like in the METS import).

I think we're confusing branches, this fix is merged in the 1.x branch and still not cherry-picked to 2.x. I've imported fiver rabits (hehehe) using 1.x and the result looks good to me (although it takes too much trying to fetch the non existing resources). See attached screenshots.

We may want to discuss the error with the "onRequest" value and maybe truncate those long file names. But I think the rest is fine.

#8 Updated by Dan Gillean over 8 years ago

  • Status changed from QA/Review to Verified

Took some troubleshooting of the import in 1.x, but I have since successfully tested this. Radda, please apply the fix to 2.x as well.


Also available in: Atom PDF