[Archivesspace_Users_Group] external_ids from AT migration included in EAD export

[Custer, Mark]

Wow.  Yeah, it looks like this change wipes out unitids from the EAD export if you migrated from the AT, like us, since ASpace stores those AT database values as external IDs, and the exporter now won’t export the “internal” IDs if you have any external ones: https://github.com/archivesspace/archivesspace/commit/1dbd894496812122107bcaf38fa213f8bbc4ae0f

In my opinion, until/unless the ASpace staff interface allows you to enter multiple unitids, then the default EAD serializer should only include the one and only unitid that a user can add to the staff interface.

In any event, due to that additional AND clause on the exporter starting at the end of line 257, it looks like the only way to address this right now is to do what Adam has done and comment out that bit of code.   You can’t just remove those unitids from your exported file, in other words, since your exported file won’t also include those unitids that you’d want to keep around!

I’ll make a JIRA ticket about this right away so that it doesn’t get lost.  Thanks for reporting it Celia, and for diagnosing it Adam!

Mark




From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Adam Jazairi
Sent: Tuesday, 22 August, 2017 2:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] external_ids from AT migration included in EAD export

Hi Celia,

Are they running 2.1.0 by any chance? We noticed similar behavior when we updated to 2.1.0, which includes some changes to the EAD exporter. As I understand it, external_ids are now serialized when multiple unit_ids are required. In our case, this replaced all component_ids in EAD exports with external_ids. We also migrated from AT, so that might be related.

A temporary workaround for us was to comment out the changes in the EAD serializer and converter and add those files to our local plugin. It's a bit ugly, but it's been working so far. Here's a link if you'd like to test it out: https://github.com/BCDigLib/bc-aspace/tree/master/archivesspace/plugins/local/backend/model<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_BCDigLib_bc-2Daspace_tree_master_archivesspace_plugins_local_backend_model&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=xa6IRQ7eTALrhdl8pKUQK7Dt1A6qc1Odh9S3_xaf-g4&s=JP4i8gRJhQ_9K90KL8F8QZ4dx5DszHYGAvWUgnhPJfU&e=>

Cheers,

Adam

On Tue, Aug 22, 2017 at 1:38 PM, Celia Caust-Ellenbogen <ccauste1 at swarthmore.edu<mailto:ccauste1 at swarthmore.edu>> wrote:
Hello all,

I'm helping out a small community archives ("WWCC") using ArchivesSpace and there's something wonky happening in their system that's not happening in mine. I'm wondering if anyone else has encountered this problem?

external_ids from the Archivists' Toolkit migration are appearing in the EAD (and therefore PDF) export as, for example: <unitid identifier="5883" type="Archivists Toolkit Database::RESOURCE_COMPONENT">5883</unitid>

In comparing WWCC's database with my institution's database, I can see that similar external_ids records from the AT migration are in my database as well, but ours aren't exporting to the EAD (as they shouldn't). Does anyone know why WWCC's external_ids are exporting?

I suspect the problem is with the EAD exporter, but WWCC says they haven't made any modifications to it, and changing it is beyond my knowledge. My back-up plan is to change the XSLT stylesheet to bypass these extra <unitid> types, but I wanted to know if anyone else knows what might be going on or has a more elegant solution.

Thanks!
Celia

--
Celia Caust-Ellenbogen
Friends Historical Library of Swarthmore College<https://urldefense.proofpoint.com/v2/url?u=http-3A__swarthmore.edu_friends-2Dhistorical-2Dlibrary&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=xa6IRQ7eTALrhdl8pKUQK7Dt1A6qc1Odh9S3_xaf-g4&s=2rHtWgr9UACW9KtLUaa4My9z14j8bNKWd4ETSQTPWXQ&e=>
610-328-8498<tel:(610)%20328-8498>
ccauste1 at swarthmore.edu<mailto:ccauste1 at swarthmore.edu>


_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=xa6IRQ7eTALrhdl8pKUQK7Dt1A6qc1Odh9S3_xaf-g4&s=dzvL6T2hYIa2DucP9hQYDB_WGvdDbFOsbMkoEkvDZrE&e=>



--
Adam Jazairi
Digital Library Applications Developer
Boston College
(617) 552-1404
adam.jazairi at bc.edu<mailto:adam.jazairi at bc.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170822/6c055acf/attachment.html>