Hi Geoff,
It looks like you have duplicate identifiers within the same finding aid document, which creates invalid EAD, which breaks the PDF export. I’m not sure if it is possible to save an archival object that doesn’t have a unique ref id, but maybe it is related to the duplicate note persistent ID issue, fixed in v. 4.2? - https://archivesspace.atlassian.net/browse/ANW-2459 It might be easier to troubleshoot this through the EAD version.
Best,
Mary
Mary Mellon (she/her)
Metadata Archivist and Section Head, Archival Materials
Rubenstein Rare Book and Manuscript Library
Duke University
--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Archivesspace_User...@lyrasislists.org.
To view this discussion visit
https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/ecaf7e9c-a3c4-4b2a-beab-b1f22a30ed8bn%40lyrasislists.org.
The trick is to know that ASpace prepends “aspace_” to the front of the identifier upon export, to ensure that the identifier satisfies the requirements of an xml:id (https://www.w3.org/TR/xml-id). Anyhow, the important bit to know is that you can just search for “890633f9925301901a0f7053eadeb4bb” in the staff interface, sans “aspace_". That will likely return two search results (maybe more!). Pick one, find the note with that Persistent ID, and then delete the contents from the Persistent ID field that has that value, then re-save the record (at which point ASpace will generate a unique ID). Such identifiers could be used for internal linking, but that’s very rare, so I don’t think it should matter much which Persistent ID field(s) you delete… but I’d go with the most-recently created search result to be safe.
Hope that helps,
Mark
External Email - Exercise Caution