[Archivesspace_Users_Group] Importing from AT to AS - File Versions left unpublished
mmcderm2 at bowdoin.edu
mmcderm2 at bowdoin.edu
Tue Apr 23 09:27:51 EDT 2019
Thank you very much – forcing a complete re-index did the trick. I’ll keep it in mind if we need to change things from outside the interface.
Mike McDermott
Bowdoin College Library
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Majewski, Steven Dennis (sdm7g)
Sent: Friday, April 19, 2019 12:22 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Importing from AT to AS - File Versions left unpublished
On Apr 19, 2019, at 11:37 AM, mmcderm2 at bowdoin.edu<mailto:mmcderm2 at bowdoin.edu> wrote:
Greetings all
We are in the process of moving from Archivists Toolkit to ArchiveSpace. I’ve been experimenting with using the AT migration plugin and everything seems to be working fine, but…
When we export an EAD file from ArchivesSpace and convert it to an html web page, the EAD file contains limited information about the DAOs attached to a resource.
It seems that when the resources are imported from AT the digital objects are set to ‘published’, but the individual File Versions in the DAOs are not set to ‘published’ – that field seems to be null instead of ‘true’ or ‘false’
I tried just running an SQL query to set all of those file version ‘published’ fields to true… and that value shows up in the staff interface, but when I export the EAD I am still getting the DAO information as if the file versions are unpublished. I need to go into each digital object individually and re-save it for the change in the file version status to take effect.
I tried the ‘Publish All’ option for the resource but that didn’t seem to make the export function see the file versions as published.
Changing values directly in SQL bypasses the step where a reindex of that resource is triggered after editing and saving it,
So there is a mismatch between the values in MySQL DB and the PUI SOLR index. Manually re-saving it triggers the reindex.
Instead of manually saving each one, you can trigger a complete reindex by deleting the files in archivesspace/data/indexer_pui_state and archivesspace/data/indexer_state and restarting the server. This is something that should always(*) be done if you are going behind the usual system checks by making changes directly in MySQL DB.
[ (*) I’m sure there are a few cases where it doesn’t matter, but safer to reindex if you’re not sure. ]
If I check the ‘include unpublished’ option in the EAD export function, I get the right DAO information, but I also get a bunch of other unpublished information in the EAD that displays in odd places in the converted HTML page.
We’ve tried creating digital objects in ArchiveSpace and the file versions are set to published there – so this would be a one time solution to fix the resources exported from Archivists Toolkit.
Is there something I can do in the export plugin that would set this value by default?
Or is there a way I can force ArchivesSpace to batch publish the file versions? Or to notice the externally set published status?
Thank you for any thoughts on this…
Mike McDermott
Bowdoin College Library
_______________________________________________
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://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flyralists.lyrasis.org%2Fmailman%2Flistinfo%2Farchivesspace_users_group&data=02%7C01%7Cmmcderm2%40bowdoin.edu%7C1d86c4ec389b4735f67f08d6c4e32f24%7C984e32e5f98a4600aa3227c3f948abe3%7C1%7C0%7C636912877358685626&sdata=x3Tposn9BYJuIjUL3KSgqPgLPASxSHC%2Blgij2qn1%2Bqg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190423/381ecaf1/attachment-0001.html>
More information about the Archivesspace_Users_Group
mailing list