[Archivesspace_Users_Group] question about customizing search features in the ArchivesSpace PUI

[Steele, Henry]

Good afternoon,

I work at Tufts University in cooperation with the Digital Collections & 
Archives.   I am working on various changes to the public user interface.  Many 
of you helped with questions before, which were a great help!

There's a change we want to make to search results.   I suspect it may involve 
getting into controllers and the functioning of ASpace, but I wanted to check, 
and ask if anyone has a plugin that does this sort of thing.

We want to change the sort options for search results so that archival objects 
appear at the top, then collections, then everything else.  So by 
json_modeltype, with two of the highest precedence.

I thought of doing this in jquery, but this wouldn't work because that would 
only sort the results on the page.

This may require development, but I wondered if someone had a direction to 
point me in, or if they had a plugin that could be modified.

Thanks

Henry Steele
Systems Librarian
Tufts University Library Technology Services
(617)627-5239

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Tools for batch updating locations in ArchivesSpace during a collections move

[Custer, Mark]

Lydia,

No, we definitely did not lose any data like that.  Any data that is already 
part of the record is posted back to the system as is, same as when you edit a 
record in the staff interface (i.e. if you change a title of a component, you 
don’t lose any notes associated with that record once you hit “save”).

The only thing that I recall right now that our approach did *not* account for 
is the fact that ArchivesSpace allows you to have multiple “current” locations 
for a single top container (e.g. 
http://test.archivesspace.org/staff/top_containers/530).  So, I think that our 
approach linked to below would have to be updated if you wanted, for whatever 
reason, to retain multiple current locations.  I was hopeful that we could have 
one “current” and 0 to more “previous” locations, but if I recall correctly, 
when you have previous locations in ArchivesSpace, those need to be marked as 
“temporary”.  So, right now, we just store one current location and ignore the 
fact that the container could have been previously shelved elsewhere.

Mark



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Tang, Lydia
Sent: Tuesday, 07 January, 2020 3:59 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Thanks for sending this, Mark!  When you did this, did you lose container 
profile info?  Just curious!
Lydia

From: 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of "Custer, Mark" mailto:mark.cus...@yale.edu>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Tuesday, January 7, 2020 at 3:57 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Bo,

Our approach was pretty similar to the approach that you linked to, in that the 
whole process is primarily broken down into three main steps:


  *   Extract and merge the data (in our case, primarily from ASpace and our 
ILS, Voyager)
  *   Compare and prep the data in a spreadsheet format
  *   Update ArchivesSpace with an edited version of that spreadsheet.

So, here’s a snippet of a CSV file that we used, with information merged from 
ASpace and Voyager:  
https://github.com/YaleArchivesSpace/data_cleanup_workgroup/blob/master/top-container-updates/python-update-scripts/ARTS-dev-test.csv

Once we verified everything was up-to-date there (we also tested the barcode 
check digit and other potential errors), we ran a simple API update to update 
all of those top containers in ArchivesSpace, with a variation of this script: 
https://github.com/YaleArchivesSpace/data_cleanup_workgroup/blob/master/top-container-updates/python-update-scripts/top-container-update.py

In our case, we were only updating three different values in ArchivesSpace:  
the barcode, the location, and the start date for when the box was added to 
that location (if no value, it would just default to the date that the script 
was run).

Updating the data in ArchivesSpace was the easy part (although it does take 
time when you have lots and lots of containers!), but you will definitely want 
to test things out a lot outside of a production system first.  Doing 
everything else is where it takes a lot more time and planning, I think.

Also, it’s been a while since I’ve looked at resources related to getting up to 
speed with ArchivesSpace and its API, but here are two that I don’t think will 
ever go out of style:


  *   Overview by Hudson Molonglo: 

Re: [Archivesspace_Users_Group] Tools for batch updating locations in ArchivesSpace during a collections move

[Custer, Mark]

Bo,

Our approach was pretty similar to the approach that you linked to, in that the 
whole process is primarily broken down into three main steps:


  *   Extract and merge the data (in our case, primarily from ASpace and our 
ILS, Voyager)
  *   Compare and prep the data in a spreadsheet format
  *   Update ArchivesSpace with an edited version of that spreadsheet.

So, here’s a snippet of a CSV file that we used, with information merged from 
ASpace and Voyager:  
https://github.com/YaleArchivesSpace/data_cleanup_workgroup/blob/master/top-container-updates/python-update-scripts/ARTS-dev-test.csv

Once we verified everything was up-to-date there (we also tested the barcode 
check digit and other potential errors), we ran a simple API update to update 
all of those top containers in ArchivesSpace, with a variation of this script: 
https://github.com/YaleArchivesSpace/data_cleanup_workgroup/blob/master/top-container-updates/python-update-scripts/top-container-update.py

In our case, we were only updating three different values in ArchivesSpace:  
the barcode, the location, and the start date for when the box was added to 
that location (if no value, it would just default to the date that the script 
was run).

Updating the data in ArchivesSpace was the easy part (although it does take 
time when you have lots and lots of containers!), but you will definitely want 
to test things out a lot outside of a production system first.  Doing 
everything else is where it takes a lot more time and planning, I think.

Also, it’s been a while since I’ve looked at resources related to getting up to 
speed with ArchivesSpace and its API, but here are two that I don’t think will 
ever go out of style:


  *   Overview by Hudson Molonglo: 
https://www.youtube.com/playlist?list=PLJFitFaE9AY_DDlhl3Kq_vFeX27F1yt6I
  *   ArchivesSpace API workshop developed by Valerie Addonizio and Lora 
Woodford:   https://github.com/archivesspace/api-training

I hope that helps,

Mark

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Bolton Kelly Doub
Sent: Tuesday, 07 January, 2020 3:20 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Hi Mark,

Thank you so much for your feedback -- this is very helpful.

And yes, your observations re: where our barcodes exist are correct:

  *   ArchivesSpace has all of our granular location info (room, row, range, 
shelf data), but no box barcodes
  *   Our ILS has the box barcodes, but much less specific location info 
(basically, there is one location code that covers the whole offsite storage 
facility that we are moving collections from)

I think we will probably end up going with some variation of the processes that 
you describe in your three bulleted suggestions. I like the approach of batch 
creating new locations rather than trying to update the existing locations. 
Regarding the use of the ArchivesSpace API to re-associate all of the 
containers to their new locations, do you have any resources, webinars, 
tutorials, github repositories, etc. that you could point us to that might help 
us start on this process? I have seen some of the resources for batch editing 
barcodes in ArchivesSpace through the API 
>,
 but I’m not sure if these address the re-association of containers to new 
locations.

To your last point, we will need to keep all of the granular locations in 
ArchivesSpace because of the way we use Aeon in connection with ArchivesSpace 
to retrieve patron requests for archival material. Though I agree with you that 
this project should serve as an opportunity to get all of the box barcodes into 
ArchivesSpace.

Thanks again for your help and please let us know about relevant API tools if 
you know of any.

Best,
Bo

Bo Doub
Archival Projects Librarian
USC Libraries Special Collections
Doheny Memorial Library, Room B22
tel:213-740-8180

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Custer, Mark
Sent: Tuesday, January 7, 2020 11:13 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Bo,

This sounds 

Re: [Archivesspace_Users_Group] Tools for batch updating locations in ArchivesSpace during a collections move

[Bolton Kelly Doub]

Hi Mark,

Thank you so much for your feedback -- this is very helpful.

And yes, your observations re: where our barcodes exist are correct:

· ArchivesSpace has all of our granular location info (room, row, 
range, shelf data), but no box barcodes

· Our ILS has the box barcodes, but much less specific location info 
(basically, there is one location code that covers the whole offsite storage 
facility that we are moving collections from)

I think we will probably end up going with some variation of the processes that 
you describe in your three bulleted suggestions. I like the approach of batch 
creating new locations rather than trying to update the existing locations. 
Regarding the use of the ArchivesSpace API to re-associate all of the 
containers to their new locations, do you have any resources, webinars, 
tutorials, github repositories, etc. that you could point us to that might help 
us start on this process? I have seen some of the resources for batch editing 
barcodes in ArchivesSpace through the API 
,
 but I’m not sure if these address the re-association of containers to new 
locations.

To your last point, we will need to keep all of the granular locations in 
ArchivesSpace because of the way we use Aeon in connection with ArchivesSpace 
to retrieve patron requests for archival material. Though I agree with you that 
this project should serve as an opportunity to get all of the box barcodes into 
ArchivesSpace.

Thanks again for your help and please let us know about relevant API tools if 
you know of any.

Best,
Bo

Bo Doub
Archival Projects Librarian
USC Libraries Special Collections
Doheny Memorial Library, Room B22
tel:213-740-8180

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Custer, 
Mark
Sent: Tuesday, January 7, 2020 11:13 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Bo,

This sounds like a very tricky / fun project!

Though I have not gone through the exact same scenario, I have gone through a 
process of matching containers in finding aids with item records in 
corresponding MARC records in an ILS.  As with most problems of this type, I 
suspect that you will find that there are a variety of data disagreements 
between the multiple systems (e.g. a finding aid that references 50 different 
boxes, whereas you might have 52 different item records for that same 
collection in your ILS) and sometimes none of them agree with reality.

It sounds like you have location data in ArchivesSpace, but no barcodes…. Is 
that right?  If so, I’d probably suggest storing both the barcodes and the 
locations in ArchivesSpace, or barring that, just adding the location data to 
your ILS and keeping the barcodes there.  Better to have all of that data in 
one system, I’d think, rather than have it split.  But, in my mind, since 
ArchivesSpace is what’s going to be describing the entire collection, in the 
long run it might be easier to have the barcodes in ArchivesSpace, since you 
can’t just create a new top container record and *not* have it linked to 
description in your finding aid, whereas you certainly can add an item record 
to your ILS and not have that linked to any description in a finding aid.

Anyhow, if your ultimate goal is to add all of this data to ArchivesSpace, I’d 
suggest:


  *   Creating new locations for the new offsite facility rather than trying to 
batch update the existing locations (since there won’t be a one-to-one 
correspondence with the container associated with those locations);
  *   Using the API to re-associate all of those containers with their new 
location;
  *   Bonus:  try to see if you can get those barcodes into ArchivesSpace, 
since at the very least trying that out will alert you to those cases where 
there’s a disagreement between what’s in both systems (that said, you can’t 
rely on simple counts alone when making that comparison, since I’ve definitely 
stumbled across cases where the finding aid might have, say, boxes 1-3, and the 
ILS for that same collection has boxes 1-2 and something else, like, oversized 
folder A… so both agree that there are 3 containers… and yet, in reality, there 
might be 4 containers: three boxes and an oversized folder labelled A).

Last, is there another system aside from ArchivesSpace that keeps track of your 
offsite locations?  I ask because you might not need to be so granular when 
creating locations in ArchivesSpace in that case.  For instance, at Yale we 
have a single location for an off-site location – in ASpace we just know that 
they are off site, and another systems keeps track exactly where that barcode 
is stored in that offsite facility.  So, perhaps it’s just wishful thinking on 
my part, but I wonder if you couldn’t just create a single 

Re: [Archivesspace_Users_Group] Trouble transferring resource

[Brian Harrington]

Hi Don,

We saw this error recently with a resource that shared a top container with 
another resource.  Since top containers are scoped to repositories, when you 
transfer a resource ASpace moves its top containers to the new repository.  But 
if a top container is linked to another resource in the old repo, ASpace can’t 
move it.  I suspect you would get this same message with any repo-scoped item 
that is linked to multiple resources.

Could this be your issue?

Brian

— 
Brian Harrington
Migration Specialist
LYRASIS
brian.harring...@lyrasis.org

> On Jan 7, 2020, at 2:09 PM, Donald Mennerich  wrote:
> 
> Laney, et al.
> 
> Has there been anything done with this situation? A user here was attempting 
> to transfer resource from repo 2 to repo 8, but we're getting an assertion 
> failed error in the log.
> 
> {
>   
> "error": "ASSERTION FAILED: {SNIP} has a repo_id of 8 but the active 
> repository is 2"
> 
> }
> 
> This transfer is working on some resources, but not others, it does not seem 
> to be related to the size of the resources. We are getting the same error in 
> the log if this is done either through the frontend or via the api. Could 
> this be the same problem that Trevor reported in this thread in 2017. We are 
> on v2.7.0.
> 
> Thanks, 
> 
> Don
> 
> Donald R. Mennerich, digital archivist
> New York University Libraries
> don.menner...@nyu.edu (212) 992-6264
> 
> 
> 
> On Mon, Jun 26, 2017 at 9:23 AM Laney McGlohon  
> wrote:
> Hey Trevor,
> 
>  
> 
> We need to change and use sessions instead of cookies for transferring large 
> resources.
> 
> I have added comment from StackOverflow (my favorite source) to the JIRA 
> ticket,
> 
>  
> 
> Here it is again:
> 
>  
> 
> Rails cookies are limited to 4KB. Note that the sessions is also stored in 
> the cookie in the default configuration. See: 
> http://guides.rubyonrails.org/security.html#session-storage
> 
> The only thing you can do about that: Do not store big objects in the cookie. 
> Store them in the database and then only store the object's id in the cookie.
> 
> This answer might also be interesting to you: 
> https://stackoverflow.com/a/4604212/2483313
> 
>  
> 
> Laney
> 
>  
> 
>  
> 
> Laney McGlohon
> 
> ArchivesSpace Tech Lead
> 
> laney.mcglo...@lyrasis.org
> 
> 800.999.8558 x2927
> 
> laneymcglohon Skype
> 
>  
> 
>  
> 
>  
> 
> From:  on behalf of 
> Trevor Thornton 
> Reply-To: Archivesspace Users Group 
> 
> Date: Friday, June 23, 2017 at 10:21 AM
> To: Archivesspace Users Group 
> 
> Subject: [Archivesspace_Users_Group] Trouble transferring resource
> 
>  
> 
> Hi-
> 
>  
> 
> We're trying to transfer a relatively large resource to a different 
> repository and the transfer keeps failing with a CookieOverflow exception 
> (the most delicious exception of all).
> 
>  
> 
> The exception response HTML is attached. We're on v. 1.5.1.
> 
>  
> 
> Anybody every experience this? Is there a cure?
> 
>  
> 
> Thanks,
> 
> Trevor Thornton
> 
>  
> 
> --
> 
> Trevor Thornton
> 
> Applications Developer, Digital Library Initiatives
> 
> North Carolina State University Libraries
> 
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group





___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Tools for batch updating locations in ArchivesSpace during a collections move

[Custer, Mark]

Bo,

This sounds like a very tricky / fun project!

Though I have not gone through the exact same scenario, I have gone through a 
process of matching containers in finding aids with item records in 
corresponding MARC records in an ILS.  As with most problems of this type, I 
suspect that you will find that there are a variety of data disagreements 
between the multiple systems (e.g. a finding aid that references 50 different 
boxes, whereas you might have 52 different item records for that same 
collection in your ILS) and sometimes none of them agree with reality.

It sounds like you have location data in ArchivesSpace, but no barcodes…. Is 
that right?  If so, I’d probably suggest storing both the barcodes and the 
locations in ArchivesSpace, or barring that, just adding the location data to 
your ILS and keeping the barcodes there.  Better to have all of that data in 
one system, I’d think, rather than have it split.  But, in my mind, since 
ArchivesSpace is what’s going to be describing the entire collection, in the 
long run it might be easier to have the barcodes in ArchivesSpace, since you 
can’t just create a new top container record and *not* have it linked to 
description in your finding aid, whereas you certainly can add an item record 
to your ILS and not have that linked to any description in a finding aid.

Anyhow, if your ultimate goal is to add all of this data to ArchivesSpace, I’d 
suggest:


  *   Creating new locations for the new offsite facility rather than trying to 
batch update the existing locations (since there won’t be a one-to-one 
correspondence with the container associated with those locations);
  *   Using the API to re-associate all of those containers with their new 
location;
  *   Bonus:  try to see if you can get those barcodes into ArchivesSpace, 
since at the very least trying that out will alert you to those cases where 
there’s a disagreement between what’s in both systems (that said, you can’t 
rely on simple counts alone when making that comparison, since I’ve definitely 
stumbled across cases where the finding aid might have, say, boxes 1-3, and the 
ILS for that same collection has boxes 1-2 and something else, like, oversized 
folder A… so both agree that there are 3 containers… and yet, in reality, there 
might be 4 containers: three boxes and an oversized folder labelled A).

Last, is there another system aside from ArchivesSpace that keeps track of your 
offsite locations?  I ask because you might not need to be so granular when 
creating locations in ArchivesSpace in that case.  For instance, at Yale we 
have a single location for an off-site location – in ASpace we just know that 
they are off site, and another systems keeps track exactly where that barcode 
is stored in that offsite facility.  So, perhaps it’s just wishful thinking on 
my part, but I wonder if you couldn’t just create a single location code in 
ArchivesSpace for the new offsite facility, and then update all of the top 
containers currently associated with the multiple locations from the current 
facility to the new one?

Mark





From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Bolton Kelly Doub
Sent: Monday, 06 January, 2020 4:01 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Tools for batch updating locations in 
ArchivesSpace during a collections move

Hi All,

At the University of Southern California, we are preparing to move a high 
volume of archival collections (basically the contents of an entire offsite 
storage building) from one offsite facility to another. We are investigating 
tools and methods for batch updating locations in ArchivesSpace to spare us 
from having to edit each location record’s building, room, row, range, shelf, 
etc. fields individually.

One additional challenge to this task is that the capacity of each destination 
shelf in the new building will not necessarily match the capacity of the 
corresponding shelving in the old offsite storage building. In many cases, a 
set of boxes that shared the same shelf in the old facility will be split up 
into different shelves in the new facility.

Most of the boxes that are moving have unique barcodes displayed on each box. 
Most of these boxes also already have locations in ArchivesSpace (with 
building, room, row, range, and shelf values applied at the box level). 
However, the box barcodes are only documented in USC’s ILS system (Alma/Primo). 
The barcodes are not documented in our instance of ArchivesSpace.

Has anyone on this list worked through a collections move under similar 
conditions using ArchivesSpace? Do you know of any relevant plugins or 
ArchivesSpace API tools that we could use to batch change locations?

Thank you in advance for any help or feedback.

Happy New Year,
Bo

Bo Doub
Archival Projects Librarian
USC Libraries Special Collections
University of Southern California
Doheny 

Re: [Archivesspace_Users_Group] Trouble transferring resource

[Donald Mennerich]

Laney, et al.

Has there been anything done with this situation? A user here was
attempting to transfer resource from repo 2 to repo 8, but we're getting an
assertion failed error in the log.

{
  "error": "ASSERTION FAILED: {SNIP} has a repo_id of 8 but the active
repository is 2"
}

This transfer is working on some resources, but not others, it does not
seem to be related to the size of the resources. We are getting the same
error in the log if this is done either through the frontend or via the
api. Could this be the same problem that Trevor reported in this thread in
2017. We are on v2.7.0.

Thanks,

Don

Donald R. Mennerich, digital archivist
New York University Libraries
don.menner...@nyu.edu (212) 992-6264



On Mon, Jun 26, 2017 at 9:23 AM Laney McGlohon 
wrote:

> Hey Trevor,
>
>
>
> We need to change and use sessions instead of cookies for transferring
> large resources.
>
> I have added comment from StackOverflow (my favorite source) to the JIRA
> ticket,
>
>
>
> Here it is again:
>
>
>
> Rails cookies are limited to 4KB. Note that the sessions is also stored in
> the cookie in the default configuration. See:
> http://guides.rubyonrails.org/security.html#session-storage
>
> The only thing you can do about that: Do not store big objects in the
> cookie. Store them in the database and then only store the object's id in
> the cookie.
>
> This answer might also be interesting to you:
> https://stackoverflow.com/a/4604212/2483313
>
>
>
> Laney
>
>
>
>
>
> *Laney McGlohon*
>
> ArchivesSpace Tech Lead
>
> laney.mcglo...@lyrasis.org
>
> 800.999.8558 x2927
>
> laneymcglohon Skype
>
>
>
>
>
>
>
> *From: * on
> behalf of Trevor Thornton 
> *Reply-To: *Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Date: *Friday, June 23, 2017 at 10:21 AM
> *To: *Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject: *[Archivesspace_Users_Group] Trouble transferring resource
>
>
>
> Hi-
>
>
>
> We're trying to transfer a relatively large resource to a different
> repository and the transfer keeps failing with a CookieOverflow exception
> (the most delicious exception of all).
>
>
>
> The exception response HTML is attached. We're on v. 1.5.1.
>
>
>
> Anybody every experience this? Is there a cure?
>
>
>
> Thanks,
>
> Trevor Thornton
>
>
>
> --
>
> Trevor Thornton
>
> Applications Developer, Digital Library Initiatives
>
> North Carolina State University Libraries
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group