From zachary.pelli at shu.edu  Wed Mar  1 11:58:37 2017
From: zachary.pelli at shu.edu (Zachary L Pelli)
Date: Wed, 1 Mar 2017 16:58:37 +0000
Subject: [Archivesspace_Users_Group] FW: "Resource has no components"
	...except it does
Message-ID: <CY4PR01MB22158E8564449EF6C31D430FE6290@CY4PR01MB2215.prod.exchangelabs.com>

We are not quite sure what is going on here but here is our issue: for some of our resources, the "Components" field at the bottom of the public view of a record will read "Resource has no components". But if you look in the frontend/admin side, the resource/component tree is clearly visible at the top of the record. This only occurs for some resources, for others the components section contains the tree as it should. We're pulling our hair out trying to figure out why some display and some do not.  I recently updated to 1.53 hoping it would resolve this issue, nut nope. If anyone has any ideas, I'm all ears. Thanks!

Zach Pelli
Digital Collections Developer
Walsh Library, Seton Hall University
973.761.2046

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/69db9699/attachment.html>

From carlos.lemus at unlv.edu  Wed Mar  1 13:08:48 2017
From: carlos.lemus at unlv.edu (Carlos Lemus)
Date: Wed, 1 Mar 2017 10:08:48 -0800
Subject: [Archivesspace_Users_Group] MARCXML export
Message-ID: <CAPsSwYpSsByYnfdzuMcCU+wzSD54O-yOs=jW611HS3x_kJxuYA@mail.gmail.com>

Hello Jessika,

Long answer:
You are not going crazy. I was able to replicate your problem and noticed
that the <prefercite>/524 tag was exporting but the text inside the note
was not. I've had some experience modifying the export marc functionality
and ran some tests. After, a couple of minutes I just noticed the note
wasn't published! Just a silly thing! so you should be able to go in your
resource, click publish on the notes and they should export in the MARC.
This really brings up the question if you want to export just your MARC
record without being shown in the public interface (which is what publish
does I believe) what are your options?

Anyways, If you ever feel like you do want to give a shot at modifying the
exports you need to create a plugin. Here are a couple examples and
tutorials

https://github.com/hudmol/yale_marcxml2accession_extras
https://github.com/l3mus/ArchivesSpace-authority-project/tree/master/unlv_marc_exporter
https://archivesspace.atlassian.net/wiki/pages/viewpage.action?pageId=18088140


Short answer:
Publish your notes.

Let me know if it works, or if you have any questions.

Carlos Lemus
Application Programmer, Special Collections Technical Services
University Libraries, University of Nevada, Las Vegas

*How often have I said to you that when you have eliminated the impossible,
whatever remains, however improbable, must be the truth? - Sherlock Holmes*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/908a1ac0/attachment.html>

From mark.custer at yale.edu  Wed Mar  1 13:49:30 2017
From: mark.custer at yale.edu (Custer, Mark)
Date: Wed, 1 Mar 2017 18:49:30 +0000
Subject: [Archivesspace_Users_Group] FW: "Resource has no
	components"	...except it does
In-Reply-To: <CY4PR01MB22158E8564449EF6C31D430FE6290@CY4PR01MB2215.prod.exchangelabs.com>
References: <CY4PR01MB22158E8564449EF6C31D430FE6290@CY4PR01MB2215.prod.exchangelabs.com>
Message-ID: <BN3PR08MB130398D1E69206455B038C788C290@BN3PR08MB1303.namprd08.prod.outlook.com>

Hi, Zach.

Just to check and make sure, could this be because you have unpublished components?

Here's an example in the sandbox of what a resource record with a single unpublished component will look like:
http://public.archivesspace.org/repositories/2/resources/7

That particular unpublished child is childless, but even if it had published components underneath of it, the display would be the same.  If you check the publish box in the admin interface for to that component, though, then it would look something like this:
http://public.archivesspace.org/repositories/2/resources/6

If that's not the issue, let us know and maybe someone else will have a better idea.

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Zachary L Pelli
Sent: Wednesday, 01 March, 2017 11:59 AM
To: ArchivesSpace List (archivesspace_users_group at lyralists.lyrasis.org) <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

We are not quite sure what is going on here but here is our issue: for some of our resources, the "Components" field at the bottom of the public view of a record will read "Resource has no components". But if you look in the frontend/admin side, the resource/component tree is clearly visible at the top of the record. This only occurs for some resources, for others the components section contains the tree as it should. We're pulling our hair out trying to figure out why some display and some do not.  I recently updated to 1.53 hoping it would resolve this issue, nut nope. If anyone has any ideas, I'm all ears. Thanks!

Zach Pelli
Digital Collections Developer
Walsh Library, Seton Hall University
973.761.2046

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/a5a475c8/attachment.html>

From zachary.pelli at shu.edu  Wed Mar  1 13:54:54 2017
From: zachary.pelli at shu.edu (Zachary L Pelli)
Date: Wed, 1 Mar 2017 18:54:54 +0000
Subject: [Archivesspace_Users_Group] FW: "Resource has
	no	components"	...except it does
In-Reply-To: <BN3PR08MB130398D1E69206455B038C788C290@BN3PR08MB1303.namprd08.prod.outlook.com>
References: <CY4PR01MB22158E8564449EF6C31D430FE6290@CY4PR01MB2215.prod.exchangelabs.com>
 <BN3PR08MB130398D1E69206455B038C788C290@BN3PR08MB1303.namprd08.prod.outlook.com>
Message-ID: <CY4PR01MB221575093B125D4ADCDAF32AE6290@CY4PR01MB2215.prod.exchangelabs.com>

Thanks for the reply.

I should have specified in the post, but the components are published (we did click the "Publish All" button), and looking at them, the "Published?" checkbox is checked.

Regards,
Zach


From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, March 1, 2017 1:50 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

Hi, Zach.

Just to check and make sure, could this be because you have unpublished components?

Here's an example in the sandbox of what a resource record with a single unpublished component will look like:
http://public.archivesspace.org/repositories/2/resources/7

That particular unpublished child is childless, but even if it had published components underneath of it, the display would be the same.  If you check the publish box in the admin interface for to that component, though, then it would look something like this:
http://public.archivesspace.org/repositories/2/resources/6

If that's not the issue, let us know and maybe someone else will have a better idea.

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Zachary L Pelli
Sent: Wednesday, 01 March, 2017 11:59 AM
To: ArchivesSpace List (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

We are not quite sure what is going on here but here is our issue: for some of our resources, the "Components" field at the bottom of the public view of a record will read "Resource has no components". But if you look in the frontend/admin side, the resource/component tree is clearly visible at the top of the record. This only occurs for some resources, for others the components section contains the tree as it should. We're pulling our hair out trying to figure out why some display and some do not.  I recently updated to 1.53 hoping it would resolve this issue, nut nope. If anyone has any ideas, I'm all ears. Thanks!

Zach Pelli
Digital Collections Developer
Walsh Library, Seton Hall University
973.761.2046

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/1e5928b0/attachment.html>

From mark.custer at yale.edu  Wed Mar  1 14:50:46 2017
From: mark.custer at yale.edu (Custer, Mark)
Date: Wed, 1 Mar 2017 19:50:46 +0000
Subject: [Archivesspace_Users_Group] FW: "Resource
	has	no	components"	...except it does
In-Reply-To: <CY4PR01MB221575093B125D4ADCDAF32AE6290@CY4PR01MB2215.prod.exchangelabs.com>
References: <CY4PR01MB22158E8564449EF6C31D430FE6290@CY4PR01MB2215.prod.exchangelabs.com>
 <BN3PR08MB130398D1E69206455B038C788C290@BN3PR08MB1303.namprd08.prod.outlook.com>
 <CY4PR01MB221575093B125D4ADCDAF32AE6290@CY4PR01MB2215.prod.exchangelabs.com>
Message-ID: <BN3PR08MB13035EF1CD9DB715913BF3C08C290@BN3PR08MB1303.namprd08.prod.outlook.com>

Zach,

Yeah, I figured that was the case, and that they weren't suppressed either, but I was hoping that the cause might be a simple one.

Since not, I'm not sure what could be causing that off hand.  Can you verify that you can get to one of the component pages in the public interface that isn't showing up in the tree view at the resource level?  For instance,  as per my previous two examples:


*         URL for the published child: http://public.archivesspace.org/repositories/2/archival_objects/3 (it displays!.. and you can grab the archival object ID, in this case "3,", directly from the staff interface)

*         URL for the unpublished child: http://public.archivesspace.org/repositories/2/archival_objects/4 (record not found message; and that's to be expected since it's unpublished and only available in the staff interface, with a similar URL: http://sandbox.archivesspace.org/resources/7#tree::archival_object_4)

I had thought that that particular part of the public interface uses the API backend, so if you're seeing them in the staff application, I would think that you should see them in the public interface.  I also think that there used to be a bug in the public interface that wouldn't display a clickable title in the tree view if a title had an EAD tag anywhere (e.g. unittitle = "Screenplay for <title>King Kong</title>"), but if that happened to be the case, then it still wouldn't display the message of "Resource has no components".  So, perhaps it's an issue that the components haven't been indexed?  Even if you don't have access to the logs and/or Solr index, you could add something to the title that would only appear in that record and then try searching in both the staff and public interface.


Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Zachary L Pelli
Sent: Wednesday, 01 March, 2017 1:55 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

Thanks for the reply.

I should have specified in the post, but the components are published (we did click the "Publish All" button), and looking at them, the "Published?" checkbox is checked.

Regards,
Zach


From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, March 1, 2017 1:50 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

Hi, Zach.

Just to check and make sure, could this be because you have unpublished components?

Here's an example in the sandbox of what a resource record with a single unpublished component will look like:
http://public.archivesspace.org/repositories/2/resources/7<https://urldefense.proofpoint.com/v2/url?u=http-3A__public.archivesspace.org_repositories_2_resources_7&d=DwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=PjInOOP-yhZdvfCxvJExNB_3mSrTAYOjE-Ld3wjgoMo&m=A_Bpo_fR6h7egzZ5zJnFKqAbpqbZG5Tf0HekTatB7vw&s=177YMiblpwW1vgDKBpuu6o31um4xdnEl-B9i8Tl29mM&e=>

That particular unpublished child is childless, but even if it had published components underneath of it, the display would be the same.  If you check the publish box in the admin interface for to that component, though, then it would look something like this:
http://public.archivesspace.org/repositories/2/resources/6<https://urldefense.proofpoint.com/v2/url?u=http-3A__public.archivesspace.org_repositories_2_resources_6&d=DwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=PjInOOP-yhZdvfCxvJExNB_3mSrTAYOjE-Ld3wjgoMo&m=A_Bpo_fR6h7egzZ5zJnFKqAbpqbZG5Tf0HekTatB7vw&s=X6ki_-jjEDWuywciBao857G_tWu_AnlPFTsFPdgnMUs&e=>

If that's not the issue, let us know and maybe someone else will have a better idea.

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Zachary L Pelli
Sent: Wednesday, 01 March, 2017 11:59 AM
To: ArchivesSpace List (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] FW: "Resource has no components" ...except it does

We are not quite sure what is going on here but here is our issue: for some of our resources, the "Components" field at the bottom of the public view of a record will read "Resource has no components". But if you look in the frontend/admin side, the resource/component tree is clearly visible at the top of the record. This only occurs for some resources, for others the components section contains the tree as it should. We're pulling our hair out trying to figure out why some display and some do not.  I recently updated to 1.53 hoping it would resolve this issue, nut nope. If anyone has any ideas, I'm all ears. Thanks!

Zach Pelli
Digital Collections Developer
Walsh Library, Seton Hall University
973.761.2046

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/376fd12b/attachment.html>

From j at minorscience.com  Wed Mar  1 23:19:29 2017
From: j at minorscience.com (Jason Loeffler)
Date: Wed, 1 Mar 2017 23:19:29 -0500
Subject: [Archivesspace_Users_Group] bar coding and migration questions
In-Reply-To: <234F6C9EA172C946BD845144C241DDD2CB482787@MSXMB1.ADMIN.ESU.EDU>
References: <234F6C9EA172C946BD845144C241DDD2CB482787@MSXMB1.ADMIN.ESU.EDU>
Message-ID: <CAP4gJsXrUn=y2GkPYwcyR=yS+ciFJw8RDRN9aMu0B7CCvs800A@mail.gmail.com>

Hi Kelly,

Recording Item-level bar codes is possible through the container module.
Yale University, who supported development of the latest version of the
container module,  has provided some useful notes here
<http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement>.

There is no way to directly import from an Access database. However, you
could certainly perform an export-based migration whereby you export your
Access data and relationships to an interim format, such as JSON or CSV,
and import the data using the API and/or one or more of the ArchivesSpace
import tools.

Let me know if that helps get your started.

Best, Jason

Jason Loeffler
Technology Consultant | The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
jason at minorscience.com
(347) 405-0826
minorscience (Skype)



On Tue, Feb 28, 2017 at 10:34 AM, Kelly J Smith <ksmith115 at po-box.esu.edu>
wrote:

> Hello,
>
>
>
> I have two questions regarding using ArchivesSpace to manage an art
> collection.
>
> Is it possible to use item-level bar coding with ArchivesSpace?
>
> Can an Access database be imported to ArchivesSpace?
>
>
>
> Thanks.
>
>
>
> Kelly Smith
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170301/0a201a0b/attachment.html>

From laney.mcglohon at lyrasis.org  Thu Mar  2 06:44:51 2017
From: laney.mcglohon at lyrasis.org (Laney McGlohon)
Date: Thu, 2 Mar 2017 11:44:51 +0000
Subject: [Archivesspace_Users_Group] Reorganization of ArchivesSpace GitHub
	Repositories
Message-ID: <91583D75-5CF6-428A-9286-5305B8143268@lyrasis.org>

The Committers? Oversight Sub-team of the Technical Advisory Council is responsible for constructing documents and policies to support the submission of code to the ArchivesSpace project and for reviewing code submitted by ArchivesSpace community developers.



Please review the attached proposal from the Sub-team for reorganizing the ArchivesSpace GitHub repositories.  We believe that this is the first step in making it easier for code commits to be integrated into the ArchivesSpace project.



We would appreciate comments and suggestions by March 17, 2017.



Thanks,

Laney





Laney McGlohon

ArchivesSpace Tech Lead

laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>

800.999.8558 x2927

laneymcglohon Skype



[cid:image001.jpg at 01D28BA1.1DCA7A10]



Save the Date for the 2017 Member Summit: October 11-12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/b6331f1e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6686 bytes
Desc: image001.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/b6331f1e/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ArchivesSpaceGitHubReorganization.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 7783 bytes
Desc: ArchivesSpaceGitHubReorganization.docx
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/b6331f1e/attachment.docx>

From trthorn2 at ncsu.edu  Thu Mar  2 10:28:37 2017
From: trthorn2 at ncsu.edu (Trevor Thornton)
Date: Thu, 2 Mar 2017 10:28:37 -0500
Subject: [Archivesspace_Users_Group] batch update of container_profile
	assignments
Message-ID: <CA+SdyS12Th=o4yCAX6whoZuscPDrbKcUTSy7BU5Z-HsegTs=ng@mail.gmail.com>

Hi everybody-

I'm trying to batch update container_profiles assigned to top_containers
using the API endpoint documented here:

http://archivesspace.github.io/archivesspace/api/#post-repositories-repo_id-top_containers-batch-container_profile

... and I'm having trouble passing the 'ids' parameter. The data type for
this parameter is '[Integer]' (with the brackets). Everything I try results
in an error complaining that the value I sent is a string and not an
[Integer], eg:

"Wanted type [Integer] but got '2'"
"Wanted type [Integer] but got '[2]'"

Can anyone explain how to correctly format the parameters for this? Any
insight is appreciated.

(BTW - we're using version 1.5.1.)

Thanks,
Trevor

-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/c2c2d9d7/attachment.html>

From sdm7g at eservices.virginia.edu  Thu Mar  2 11:22:35 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Thu, 2 Mar 2017 16:22:35 +0000
Subject: [Archivesspace_Users_Group] batch update of
	container_profile	assignments
In-Reply-To: <CA+SdyS12Th=o4yCAX6whoZuscPDrbKcUTSy7BU5Z-HsegTs=ng@mail.gmail.com>
References: <CA+SdyS12Th=o4yCAX6whoZuscPDrbKcUTSy7BU5Z-HsegTs=ng@mail.gmail.com>
Message-ID: <CC47C005-7E72-4CA4-8D3B-35556A869645@eservices.virginia.edu>


I haven?t used that API endpoint, but for all of the ones that can take an array of values, for example accessing resources with id_set[] param, the URL syntax is something like:

/repositories/3/resources?id_set[]=230&id_set[]=223&id_set[]=222

so for that endpoint, you probably want to append ??id[]=2? to the URL.

And if you?re using curl, remember to use the ?-g? (glob off) option so it doesn?t interpret ?[]? internally.

? Steve.



On Mar 2, 2017, at 10:28 AM, Trevor Thornton <trthorn2 at ncsu.edu<mailto:trthorn2 at ncsu.edu>> wrote:

Hi everybody-

I'm trying to batch update container_profiles assigned to top_containers using the API endpoint documented here:

http://archivesspace.github.io/archivesspace/api/#post-repositories-repo_id-top_containers-batch-container_profile

... and I'm having trouble passing the 'ids' parameter. The data type for this parameter is '[Integer]' (with the brackets). Everything I try results in an error complaining that the value I sent is a string and not an [Integer], eg:

"Wanted type [Integer] but got '2'"
"Wanted type [Integer] but got '[2]'"

Can anyone explain how to correctly format the parameters for this? Any insight is appreciated.

(BTW - we're using version 1.5.1.)

Thanks,
Trevor

--
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/e3ea2c3b/attachment.html>

From trthorn2 at ncsu.edu  Thu Mar  2 12:20:35 2017
From: trthorn2 at ncsu.edu (Trevor Thornton)
Date: Thu, 2 Mar 2017 12:20:35 -0500
Subject: [Archivesspace_Users_Group] batch update of container_profile
	assignments
In-Reply-To: <CC47C005-7E72-4CA4-8D3B-35556A869645@eservices.virginia.edu>
References: <CA+SdyS12Th=o4yCAX6whoZuscPDrbKcUTSy7BU5Z-HsegTs=ng@mail.gmail.com>
 <CC47C005-7E72-4CA4-8D3B-35556A869645@eservices.virginia.edu>
Message-ID: <CA+SdyS2MXCJfgS8DhXqc0bVnna+zuRMHNbjsF46fNC1pB7KKHA@mail.gmail.com>

That totally works. Thanks Steve!

On Thu, Mar 2, 2017 at 11:22 AM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu> wrote:

>
> I haven?t used that API endpoint, but for all of the ones that can take an
> array of values, for example accessing resources with id_set[] param, the
> URL syntax is something like:
>
> /repositories/3/resources?id_set[]=230&id_set[]=223&id_set[]=222
>
> so for that endpoint, you probably want to append ??id[]=2? to the URL.
>
> And if you?re using curl, remember to use the ?-g? (glob off) option so it
> doesn?t interpret ?[]? internally.
>
> ? Steve.
>
>
>
> On Mar 2, 2017, at 10:28 AM, Trevor Thornton <trthorn2 at ncsu.edu> wrote:
>
> Hi everybody-
>
> I'm trying to batch update container_profiles assigned to top_containers
> using the API endpoint documented here:
>
> http://archivesspace.github.io/archivesspace/api/#post-
> repositories-repo_id-top_containers-batch-container_profile
>
> ... and I'm having trouble passing the 'ids' parameter. The data type for
> this parameter is '[Integer]' (with the brackets). Everything I try results
> in an error complaining that the value I sent is a string and not an
> [Integer], eg:
>
> "Wanted type [Integer] but got '2'"
> "Wanted type [Integer] but got '[2]'"
>
> Can anyone explain how to correctly format the parameters for this? Any
> insight is appreciated.
>
> (BTW - we're using version 1.5.1.)
>
> Thanks,
> Trevor
>
> --
> Trevor Thornton
> Applications Developer, Digital Library Initiatives
> North Carolina State University Libraries
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/9c0ef359/attachment.html>

From marianne.swierenga at wmich.edu  Thu Mar  2 14:38:35 2017
From: marianne.swierenga at wmich.edu (Marianne Swierenga)
Date: Thu, 2 Mar 2017 19:38:35 +0000
Subject: [Archivesspace_Users_Group] Top containers are not being assigned
	to collection
Message-ID: <SN2PR0801MB2365FAF6E80EC4787BFDCE7592280@SN2PR0801MB2365.namprd08.prod.outlook.com>

When adding a new top container instance to a collection, they are not assigned to the collection somehow, unlike the ones I created in the exact same way before. So when I search for them by resource in Manage Top Container, they do not come up. 

When I located them in Manage Top Container, they do not have a Resource/Accession listed. 

I feel like there is a quick fix out there but I don't understand why they are not linking in the first place.

Thanks,
Marianne

--
Marianne Swierenga, MFA, MLIS
Metadata and Digital Resources Specialist
University Libraries (Waldo Library)
Western Michigan University
1903 W. Michigan Ave.
Kalamazoo MI 49008-5353 USA
(269) 387-4112

From j at minorscience.com  Thu Mar  2 19:52:55 2017
From: j at minorscience.com (Jason Loeffler)
Date: Thu, 2 Mar 2017 19:52:55 -0500
Subject: [Archivesspace_Users_Group] Changing subject term breaks records
	displayed in Linked Records pane
Message-ID: <CAP4gJsUmdJ1KL2fPJsHiW8=OGFZdZPMdUk6B2x+chM9MrSDYJA@mail.gmail.com>

Pursuant to the following ticket
<https://archivesspace.atlassian.net/browse/AR-1650>. Steps to reproduce:

   - Create a subject and attach it to an archival object (e.g.
   "Architecture")
   - Associate subject with an archival object
   - Archival object appears in the subject's Linked Records pane
   - Make change to a subject term (e.g. "Architecture" to "Architecture,
   general")
   - Archival object no longer appears in subject's Linked Records pane

Rebuilding the index, the archival objects appear again in the subjects
Linked Records pane. Can anyone else reproduce or otherwise describe
whether this is desired behavior?

Thanks, Jason

Jason Loeffler
Technology Consultant | The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
jason at minorscience.com
(347) 405-0826
minorscience (Skype)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170302/568757a2/attachment.html>

From christine.dibella at lyrasis.org  Fri Mar  3 08:01:27 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Fri, 3 Mar 2017 13:01:27 +0000
Subject: [Archivesspace_Users_Group] Top containers are not being
	assigned	to collection
In-Reply-To: <SN2PR0801MB2365FAF6E80EC4787BFDCE7592280@SN2PR0801MB2365.namprd08.prod.outlook.com>
References: <SN2PR0801MB2365FAF6E80EC4787BFDCE7592280@SN2PR0801MB2365.namprd08.prod.outlook.com>
Message-ID: <SN1PR08MB140607F5E1239742A011DBA9F12B0@SN1PR08MB1406.namprd08.prod.outlook.com>

Dear Marianne,

It is possible to create a top container that is not linked to an accession or resource, or is linked to multiple accessions or resources. So the first thing to check is that you are not inadvertently doing this. The key is if you create the top container with an accession or resource, link it, but then do not save the accession record or resource record to preserve the link, the top container will be created but it won't have the association you're intending. To see this, in the sandbox (http://sandbox.archivesspace.org - user name is admin and password is admin) right now there's an example of a top container I did this with (its indicator is example 1). It is findable if I do an Unassociated containers search, but not otherwise. It's possible to rectify this by adding another instance to the accession or resource, selecting the Browse option in the top container field, and locating the top container you created before (doing an unassociated containers search). Once you save it to the record the link you're expecting will be there.

(Also in the sandbox is an example of a top container that is properly linked and saved to a resource (see http://sandbox.archivesspace.org/resources/12#tree::resource_12). Its indicator is example 2. As you can see by the blue representation (blue means a linked record in ArchivesSpace) of it in the instances area, it is linked.)

If your top containers are showing the links you expect in the associated accessions or resources, the other culprit might be an indexing lag. Indexing can be dependent on a number of factors, both locally and within the application. Which version of ArchivesSpace are you using, and are you having problems locating any other types of records?

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)


-----Original Message-----
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Marianne Swierenga
Sent: Thursday, March 2, 2017 2:39 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Top containers are not being assigned to collection

When adding a new top container instance to a collection, they are not assigned to the collection somehow, unlike the ones I created in the exact same way before. So when I search for them by resource in Manage Top Container, they do not come up. 

When I located them in Manage Top Container, they do not have a Resource/Accession listed. 

I feel like there is a quick fix out there but I don't understand why they are not linking in the first place.

Thanks,
Marianne

--
Marianne Swierenga, MFA, MLIS
Metadata and Digital Resources Specialist University Libraries (Waldo Library) Western Michigan University
1903 W. Michigan Ave.
Kalamazoo MI 49008-5353 USA
(269) 387-4112
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

From kiddm at vcu.edu  Fri Mar  3 09:46:44 2017
From: kiddm at vcu.edu (Margaret Kidd)
Date: Fri, 3 Mar 2017 09:46:44 -0500
Subject: [Archivesspace_Users_Group] Basics of Archives and Digital
 Objects Training
In-Reply-To: <c1536bdbd96e4a3bbc29ecee5c5954b3@EXMBX03.campus.wm.edu>
References: <c1536bdbd96e4a3bbc29ecee5c5954b3@EXMBX03.campus.wm.edu>
Message-ID: <CAB+m3uuYzZQwfKcmQQyC0F3E2oNOZw+fvjuQnw8fVrvE3u12jA@mail.gmail.com>

Hi Christina,

I was wondering where we should park. Also, are there places close by for
lunch that we can walk to or would we need to drive?

Thanks,

Margaret


------------------------------

Margaret T. Kidd

Project Archivist, Special Collections & Archives

VCU Libraries | Tompkins-McCaw Library for the Health Sciences

509 N. 12th Street/PO Box 980582, Richmond, VA 23298-0582

(804) 828-3152
[image: em_twitter.png] <https://twitter.com/VCUTMLibrary> [image:
em_fb.png] <https://www.facebook.com/VCUTMLib>


<http://www.vcu.edu/>      <http://vaheritage.org>


On Tue, Feb 21, 2017 at 5:00 PM, Luers, Christina <crluers at wm.edu> wrote:

> Archives Space members,
>
>
>
> We are happy to announce that we are able to host Archives Space training
> at the College of William and Mary in Williamsburg, VA.  Training will take
> place over a three day period from March 6 (Monday) to March 8
> (Wednesday).  The first two days will cover the Basics and will focus on
> the staff entry of accessions and resources along with various aspects of
> the staff interface.  The third day is a Digital Objects workshop focused
> solely on creating and managing digital objects within the functions of
> Archives Space.  The training will occur in Swem Library?s Ford Classroom.
> All three days will start around 9am and end close to 5pm with breaks
> worked into the day throughout and also for lunch.
>
>
>
> If you would like to attend, please respond to crluers at wm.edu with names
> and contact information for each attendee.  Please also indicate if you can
> bring your own laptop or if you will need for us to provide one to you for
> your training.
>
>
>
> There is no charge for these workshops, and we still have plenty of room.
> Please respond by 27 February 2017.
>
>
>
>
>
> Best,
>
>
>
> Christina Luers
>
> crluers at wm.edu
>
>
>
>
>
> Christina R. Luers
>
> Archives Collections Specialist
>
> Special Collections Research Center
>
> Earl Gregg Swem Library College of William and Mary
>
> P.O. Box 8794
>
> Williamsburg, VA 23187-8794
>
>
>
> crluers at wm.edu
>
> 757-221-3096 <(757)%20221-3096>
>
>
>
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170303/437539e0/attachment.html>

From christine.dibella at lyrasis.org  Mon Mar  6 09:09:12 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Mon, 6 Mar 2017 14:09:12 +0000
Subject: [Archivesspace_Users_Group] call for planning group for
	ArchivesSpace Member Forum at SAA 2017
Message-ID: <SN1PR08MB1406804D23E67DD3D7F20E79F12C0@SN1PR08MB1406.namprd08.prod.outlook.com>

Hello ArchivesSpace members,

Plans are underway for this year's ArchivesSpace Members Forum, which will be held at Portland State University on July 25, 2017. This event will again be held in conjunction with the SAA conference, though we're hoping to also have an online component for those who can't attend in person. Like last year, we're looking to do a program that combines workshops, sessions, discussion groups, and program updates. It will be free and open to all staff of ArchivesSpace member institutions.

I'm looking for some ArchivesSpace members to assist me with developing the format and program, organizing face-to-face and online events, and, ideally, helping with logistics at the forum itself. If you're not planning to go to SAA this year, we could certainly still use help before and afterwards, but as you would imagine it's really useful to have as many people there to pitch in on the day of as we can. The overall time commitment will be less than 5 hours a month through July, plus any time spent at the forum itself.

Please drop me a line if you'd like to be involved and let me know whether or not you plan to attend SAA or otherwise be in Portland on July 25. I'm aiming to convene a first (phone) meeting of the planning group later this month.

If you need more information at this point, please just let me know. Thanks in advance!

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/ede56bfb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/ede56bfb/attachment.jpg>

From christine.dibella at lyrasis.org  Mon Mar  6 12:21:30 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Mon, 6 Mar 2017 17:21:30 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace Update - March 2017
Message-ID: <SN1PR08MB1406DE91425B31D3FDB37898F12C0@SN1PR08MB1406.namprd08.prod.outlook.com>

[ASpaceOrgHome.jpg]

March 2017 Update


Development

The ArchivesSpace team was pleased to release version 1.5.3 on February 15.  This minor release has some bug fixes, including a fix for the issue with resource components being exported in EAD in a different order from how they appear in the staff interface (https://archivesspace.atlassian.net/browse/AR-1620), as well as improvements to overall performance. It features work from our development partner, Hudson Molonglo (HM), as well as code contributions from community members Mark Cooper, Steve Majewski, Chris Fitzpatrick, Jason Loeffler, and Michael Bond. Thanks to all who contributed, participated in testing and provided the feedback that led to these improvements!

You can download the new release from Github at https://github.com/archivesspace/archivesspace/releases/tag/v1.5.3. The release page<https://github.com/archivesspace/archivesspace/releases/tag/v1.5.3> has a listing of all the new features and bug fixes included in this release.

Big thanks as always to Mark Cooper, Blake Carver, and the other staff of LYRASIS' Digital Technology Services for their testing and technical support. We were also pleased to celebrate the first regular release managed by ArchivesSpace's new Tech Lead, Laney McGlohon.

The next release of ArchivesSpace will reflect significant improvements in the underlying technology for the application, including upgrades to Rails 5 and JRuby 9.1.x. It will also feature the beta of the new public interface. To reflect the significance of these changes, the next version will be numbered 2.0.0. If you are looking ahead and thinking about IT resources needed for the 2.0.0 upgrade, please keep in mind that these changes will affect plugins and some local modifications. We'll provide more guidance about how to adapt your plugins and modifications as we get closer to the final release. Also, this upgrade will require a complete re-index of your database. More information about 2.0.0 will be shared as the month progresses and we will be holding a webinar close to the time of the release that highlights the changes from a user and technological standpoint.


Save the Date

The 2017 ArchivesSpace Member Forum will be held on Tuesday, July 25, at Portland State University. This event is open to all staff from ArchivesSpace member institutions and will feature a variety of opportunities to learn and share about all things ArchivesSpace. We are currently assembling the planning group and will be posting a call for sessions very soon. If you'd like to volunteer for either, please email Christine Di Bella at christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>.


Membership Update

Our new members since February 1 include:

*         Georgia State University

*         Point No Point Treaty Council (Poulsbo, Washington)

*         Southeast Missouri State University

*         St. Edward's University (Austin, Texas)

*         Tacoma Community College

*         University of Vermont

The School of Information and Library Science at the University of North Carolina at Chapel Hill also joined us as an Educational Program member.

As of March 6, we have 321 General members, 12 Educational Program members, and 3 Registered Service Providers. If you are interested in your institution becoming a member of ArchivesSpace, please email us at ArchivesSpaceHome at lyrasis.org<mailto:ArchivesSpaceHome at lyrasis.org> for more information.


Connect with ArchivesSpace in Person

Tech Lead Laney McGlohon will be participating in a number of activities at Code4Lib in Los Angeles from March 6-9. She'll be speaking on a panel with representatives from Archivematica and Hydra-in-a-Box on March 7, and staffing an exhibitor table during the conference breaks and in between sessions. Later in the month Laney will be back in the West Coast at LDCX, an unconference held at Stanford University, from March 27-29. She'd love to chat with you about your ideas and experience with ArchivesSpace, especially if you'd like to get involved in development. Please email Laney at laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org> or catch her in person if you'd like to meet up.

Program Manager Christine Di Bella, as well as Madeline Sheldon from LYRASIS' Digital Technology Services, will be at the New England Archivists spring meeting in Hyannis, Massachusetts, from March 24-25. Stop by our exhibitor tables to check in about the ArchivesSpace application, membership, and hosting services.

We'll also be represented at the Society of North Carolina Archivists annual meeting in Asheville, North Carolina, where ArchivesSpace instructor Noah Huffman will be teaching a one-day Introduction to ArchivesSpace workshop on March 15. If you're interested in hosting an ArchivesSpace workshop at your local or regional archives group meeting, please get in touch with Christine about possibilities.


ArchivesSpace monthly updates provide news about ArchivesSpace community and program activities and are sent to our member listservs, the ArchivesSpace Google Group, and SAA's Collection Management Tools roundtable listserv, as well as being posted on the ArchivesSpace website. Please feel free to share this update with people you know who have an interest in ArchivesSpace but may not be on one of these lists.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/c6bdfb40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 7679 bytes
Desc: image003.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/c6bdfb40/attachment.jpg>

From Tony.Kurtz at wwu.edu  Mon Mar  6 12:53:39 2017
From: Tony.Kurtz at wwu.edu (Tony Kurtz)
Date: Mon, 6 Mar 2017 17:53:39 +0000
Subject: [Archivesspace_Users_Group] Top containers as box-folder
Message-ID: <DM5PR02MB242807BE3E19FAB331234C20952C0@DM5PR02MB2428.namprd02.prod.outlook.com>

Greetings,
I've searched around but I don't think I've been able to find an answer to an issue we're having.  If I'm mistaken I'll happily endure the embarrassment along with the solution!

We are planning an upgrade from AS 1.4.2 to 1.5 and we are doing an assessment of how our top containers will look post-upgrade.  One of our repositories expresses almost all containers with a type indicator of "box-folder" and a value expressed as a box/folder pair, e.g. "1/1", "1/2", etc. (and all box/folder expressions are unique within a collection-i.e., each "b/f" value is not repeated). From what we can tell, it looks like the 1.5 upgrade process will result in top containers being created at the folder level.  However, we want top containers to be at the box level.  Is our assumption correct that top containers will be created as folders?  Does anyone have advice on how best to navigate this so that we can ensure that boxes are our top containers-e.g. is there anything we can do prior to the upgrade to make this work out as we wish, or will we just need to do the work post-ugrade?

Thanks

Tony Kurtz
Western Washington University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/55279a90/attachment.html>

From sdm7g at eservices.virginia.edu  Mon Mar  6 13:41:24 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Mon, 6 Mar 2017 18:41:24 +0000
Subject: [Archivesspace_Users_Group] Top containers as box-folder
In-Reply-To: <DM5PR02MB242807BE3E19FAB331234C20952C0@DM5PR02MB2428.namprd02.prod.outlook.com>
References: <DM5PR02MB242807BE3E19FAB331234C20952C0@DM5PR02MB2428.namprd02.prod.outlook.com>
Message-ID: <BE7C2AB4-C39F-46FD-93FF-178A4DCFFEF0@eservices.virginia.edu>


We had this problem as well. See previous thread in mailing list:

http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2016-November/004238.html


I believe it?s a lot easier to fix the problem in 1.4.2 before migration, where it can be done in MySQL, than to try to fix it afterwards when top_container become independent linked objects: a lot simpler to just change a couple values in a table than to deal with deleting and creating top_containers.

In our case it was a bit more complicated because some of the container type enums had already been merged and changed, so it required pulling info from a previous mysqldump and creating a view over several tables.
In your case, I think you can just lookup the container type ids for ?box?, ?folder? and ?box/folder? and update the container values where type_1_id = [box/folder id] AND type_2_id IS NULL and indicator_1 LIKE ?%/%? and indicator_2 is NULL.


You might want to first do some exploring of table values in MySQL to check that there aren?t any false positives. I also tested everything out on a local test server with a database cloned from mysqldump of production database, before trying the procedure on production data.


? Steve.


On Mar 6, 2017, at 12:53 PM, Tony Kurtz <Tony.Kurtz at wwu.edu<mailto:Tony.Kurtz at wwu.edu>> wrote:

Greetings,
I?ve searched around but I don?t think I?ve been able to find an answer to an issue we?re having.  If I?m mistaken I?ll happily endure the embarrassment along with the solution!

We are planning an upgrade from AS 1.4.2 to 1.5 and we are doing an assessment of how our top containers will look post-upgrade.  One of our repositories expresses almost all containers with a type indicator of ?box-folder? and a value expressed as a box/folder pair, e.g. ?1/1?, ?1/2?, etc. (and all box/folder expressions are unique within a collection?i.e., each ?b/f? value is not repeated). From what we can tell, it looks like the 1.5 upgrade process will result in top containers being created at the folder level.  However, we want top containers to be at the box level.  Is our assumption correct that top containers will be created as folders?  Does anyone have advice on how best to navigate this so that we can ensure that boxes are our top containers?e.g. is there anything we can do prior to the upgrade to make this work out as we wish, or will we just need to do the work post-ugrade?

Thanks

Tony Kurtz
Western Washington University
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170306/6ab70d7c/attachment.html>

From eric.milenkiewicz at ucr.edu  Tue Mar  7 15:22:29 2017
From: eric.milenkiewicz at ucr.edu (Eric Milenkiewicz)
Date: Tue, 7 Mar 2017 20:22:29 +0000
Subject: [Archivesspace_Users_Group] Export options for User Permission
	Groups?
Message-ID: <CY4PR01MB2312978C97A464D78BF16206F42F0@CY4PR01MB2312.prod.exchangelabs.com>

Hi All,

We have provided reference staff with Viewer access to our ASpace instance (1.4.2), however they cannot access any of the export options namely "Print Resource to PDF." This would be extremely helpful in reference interactions pertaining to in-process/partially processed collections that are not yet available through the public interface. The export option does not become available until the "Advanced Data Entry" level which provides more privileges than we would like to grant here. And exports aren't listed as one of the Manage Groups functions that can be toggled on/off.

I'm curious to hear if others are facing similar issues and if there are any workarounds/planned improvements in this area? Thanks.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/cf0fefa7/attachment.html>

From eric.milenkiewicz at ucr.edu  Tue Mar  7 15:35:26 2017
From: eric.milenkiewicz at ucr.edu (Eric Milenkiewicz)
Date: Tue, 7 Mar 2017 20:35:26 +0000
Subject: [Archivesspace_Users_Group] Processors ability to delete?
Message-ID: <CY4PR01MB23121C156D279C04BE9EE218F42F0@CY4PR01MB2312.prod.exchangelabs.com>

Hi All,

We have recently hired/trained student employees on processing archival collections in ASpace, however we cannot seem to find a way of fine tuning the user permission groups to provide them with an appropriate level of access.

For example, the advanced/basic data entry staff and archivist levels do not allow permissions for resource component records to be deleted (which is often times needed while processing, as things change). This level of access is not achieved until the repository/project manager level which provides much greater permissions. Configuring the User Permission Groups also has not helped here since once the "delete the major record types in this repository" option is checked then entire Resource and Accession records can be deleted (a function we want to restrict to higher level staff).

Has anyone else run into this type of permissions issue? And if so, have you identified any workarounds?

Thanks,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/a3606989/attachment.html>

From egadsby at towson.edu  Tue Mar  7 15:57:12 2017
From: egadsby at towson.edu (Gadsby, Eric T.)
Date: Tue, 7 Mar 2017 20:57:12 +0000
Subject: [Archivesspace_Users_Group] Limiting RAM usage by Java and AS
Message-ID: <403F67E7-9ADC-45D4-8792-4188F228FAE2@towson.edu>

Good afternoon. Has anybody had any experience with this? We are using the standard Jetty set up. Thanks in advance for the community?s help! 

Eric T Gadsby ? IT Operations Specialist
 
University Libraries <http://libraries.towson.edu>
Towson University <http://www.towson.edu/> ? 8000 York Road ? Towson, Maryland,  21252-0001
p. 410-704-3340
 <http://www.towson.edu/>
 
Confidentiality Notice: This message may contain information that is confidential, privileged, proprietary, or otherwise legally exempt from disclosure. If you are not the intended recipient, you are notified that you are not authorized to read, print, copy or disseminate this message, any part of it, or any attachments. If this message has been sent to you in error, please notify the sender by replying to this transmission, or by calling University Libraries at 410-704-3340. 
 
 

On 2/16/17, 3:39 PM, "archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Gadsby, Eric T." <archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of egadsby at towson.edu> wrote:

    Dear Friends,
    
    We our AS install is eating up a lot of RAM as Java is known to do. I know other Java based applications I have administered sometimes have ways to limit java ram usage. Is this true for AS?  If so how does one do it. Please pardon if the question asked before. Thanks! 
    
    Sincerely,
    
    Eric T Gadsby
    IT Operations Specialist, Cook Library
    Towson University
    egadsby at towson.edu
    410-704-3340
    
    _______________________________________________
    Archivesspace_Users_Group mailing list
    Archivesspace_Users_Group at lyralists.lyrasis.org
    http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
    


From lcalahan at umn.edu  Tue Mar  7 15:58:34 2017
From: lcalahan at umn.edu (Lisa Calahan)
Date: Tue, 7 Mar 2017 14:58:34 -0600
Subject: [Archivesspace_Users_Group] Processors ability to delete?
In-Reply-To: <CY4PR01MB23121C156D279C04BE9EE218F42F0@CY4PR01MB2312.prod.exchangelabs.com>
References: <CY4PR01MB23121C156D279C04BE9EE218F42F0@CY4PR01MB2312.prod.exchangelabs.com>
Message-ID: <CAFfoRK5nazmCizTGUdXaXdPcbzkkWGm6JEimvPBD05tujsK_hA@mail.gmail.com>

Hi Eric,

We have also run into this issue. It would be a great feature if the
deletion of component records could be a separate permission from the
"delete all major record types in this repository."

We have a couple of workarounds that we've used, none of which are really
sustainable. 1) A student/staff person will report when they need a
component record deleted and a staff person with that permission will
delete the record for them (usually happens when a component record was
accidentally duplicated) and a supervisor is sitting close by. 2) The
repository manager or ASpace administrator will temporarily give the
permission group "delete the major record types of this repository"
permission to be able to delete; which is paired with a stern talking to
about being careful to not delete a resource record. 3) Move
multiple/various component records that need to be deleted into a "To
delete" grouping/fake series at the end of the resource record to have a
supervisor delete as one of the final review tasks.

Best,
Lisa

On Tue, Mar 7, 2017 at 2:35 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu
> wrote:

> Hi All,
>
>
>
> We have recently hired/trained student employees on processing archival
> collections in ASpace, however we cannot seem to find a way of fine tuning
> the user permission groups to provide them with an appropriate level of
> access.
>
>
>
> For example, the advanced/basic data entry staff and archivist levels do
> not allow permissions for resource component records to be deleted (which
> is often times needed while processing, as things change). This level of
> access is not achieved until the repository/project manager level which
> provides much greater permissions. Configuring the User Permission Groups
> also has not helped here since once the ?delete the major record types in
> this repository? option is checked then entire Resource and Accession
> records can be deleted (a function we want to restrict to higher level
> staff).
>
>
>
> Has anyone else run into this type of permissions issue? And if so, have
> you identified any workarounds?
>
>
>
> Thanks,
>
>
> Eric Milenkiewicz
>
> Manuscripts Curator
>
> Special Collections & University Archives
>
> UCR Library
>
> 951-827-4942 <(951)%20827-4942>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 

Head of Archival Processing

University of Minnesota Libraries
Archives and Special Collections
Elmer L. Andersen Library, Suite 315
222-21st Ave. S.
Minneapolis MN 55455

Phone: 612.626.2531
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/732a26bf/attachment.html>

From sdm7g at eservices.virginia.edu  Tue Mar  7 16:04:39 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Tue, 7 Mar 2017 21:04:39 +0000
Subject: [Archivesspace_Users_Group] Export options for User
	Permission	Groups?
In-Reply-To: <CY4PR01MB2312978C97A464D78BF16206F42F0@CY4PR01MB2312.prod.exchangelabs.com>
References: <CY4PR01MB2312978C97A464D78BF16206F42F0@CY4PR01MB2312.prod.exchangelabs.com>
Message-ID: <D19993AF-84F9-4875-B43F-3AEC7D6F5DE6@eservices.virginia.edu>


I believe if you add ?initiate import jobs? permission to the group, although the option will not show up when viewing the resource, you can click on "Create/Background Jobs? menu and download a PDF that way. However that?s probably still granting more permissions than you want. I believe that now that there are other types of batch jobs, ?import? applies to all batch jobs. Yes: it?s often difficult to figure out what permission you need to turn on for a particular use case. Another alternative is to enable the aspace-public-formats plugin and then you can download PDF from the public web server.


In general: Yes ? I?ve had problems with the ArchivesSpace permissions system. In some places it doesn?t grant even read permission to things that you don?t have permission to change. I believe that?s the case for repository information.  I know there are more ? I?m sorry I haven?t been keeping a list of the issues as they come up. Another issue is that users can?t change their own passwords ? they need an admin to set them.

? Steve.



On Mar 7, 2017, at 3:30 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<mailto:eric.milenkiewicz at ucr.edu>> wrote:

Hi All,

We have provided reference staff with Viewer access to our ASpace instance (1.4.2), however they cannot access any of the export options namely ?Print Resource to PDF.? This would be extremely helpful in reference interactions pertaining to in-process/partially processed collections that are not yet available through the public interface. The export option does not become available until the ?Advanced Data Entry? level which provides more privileges than we would like to grant here. And exports aren?t listed as one of the Manage Groups functions that can be toggled on/off.

I?m curious to hear if others are facing similar issues and if there are any workarounds/planned improvements in this area? Thanks.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/9b52be7a/attachment.html>

From sdm7g at eservices.virginia.edu  Tue Mar  7 16:10:16 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Tue, 7 Mar 2017 21:10:16 +0000
Subject: [Archivesspace_Users_Group] Processors ability to delete?
In-Reply-To: <CAFfoRK5nazmCizTGUdXaXdPcbzkkWGm6JEimvPBD05tujsK_hA@mail.gmail.com>
References: <CY4PR01MB23121C156D279C04BE9EE218F42F0@CY4PR01MB2312.prod.exchangelabs.com>
 <CAFfoRK5nazmCizTGUdXaXdPcbzkkWGm6JEimvPBD05tujsK_hA@mail.gmail.com>
Message-ID: <6276AE0B-B23A-4747-AC17-3ACDC684C372@eservices.virginia.edu>


We?ve also run into this where people can create a resource, but can?t delete it if they make a mistake and want to start over, or just want to create a test object when learning.  But in general, I think it?s a good idea to make deleting a record more privileged. Maybe a useful feature would be to make the permission behavior dependent on resource status - perhaps make only published items require elevated permission to delete, or else make a exception for ?draft? status or some other value.


On Mar 7, 2017, at 3:58 PM, Lisa Calahan <lcalahan at umn.edu<mailto:lcalahan at umn.edu>> wrote:

Hi Eric,

We have also run into this issue. It would be a great feature if the deletion of component records could be a separate permission from the "delete all major record types in this repository."

We have a couple of workarounds that we've used, none of which are really sustainable. 1) A student/staff person will report when they need a component record deleted and a staff person with that permission will delete the record for them (usually happens when a component record was accidentally duplicated) and a supervisor is sitting close by. 2) The repository manager or ASpace administrator will temporarily give the permission group "delete the major record types of this repository" permission to be able to delete; which is paired with a stern talking to about being careful to not delete a resource record. 3) Move multiple/various component records that need to be deleted into a "To delete" grouping/fake series at the end of the resource record to have a supervisor delete as one of the final review tasks.

Best,
Lisa

On Tue, Mar 7, 2017 at 2:35 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<mailto:eric.milenkiewicz at ucr.edu>> wrote:
Hi All,

We have recently hired/trained student employees on processing archival collections in ASpace, however we cannot seem to find a way of fine tuning the user permission groups to provide them with an appropriate level of access.

For example, the advanced/basic data entry staff and archivist levels do not allow permissions for resource component records to be deleted (which is often times needed while processing, as things change). This level of access is not achieved until the repository/project manager level which provides much greater permissions. Configuring the User Permission Groups also has not helped here since once the ?delete the major record types in this repository? option is checked then entire Resource and Accession records can be deleted (a function we want to restrict to higher level staff).

Has anyone else run into this type of permissions issue? And if so, have you identified any workarounds?

Thanks,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942<tel:(951)%20827-4942>


_______________________________________________
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




--

Head of Archival Processing

University of Minnesota Libraries
Archives and Special Collections
Elmer L. Andersen Library, Suite 315
222-21st Ave. S.
Minneapolis MN 55455

Phone: 612.626.2531
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/8f4592ab/attachment.html>

From ltang5 at mail.lib.msu.edu  Tue Mar  7 16:11:47 2017
From: ltang5 at mail.lib.msu.edu (Tang, Lydia)
Date: Tue, 7 Mar 2017 21:11:47 +0000
Subject: [Archivesspace_Users_Group] PDFS and question on editing
	auto-populated fields
Message-ID: <BFF92F78-864B-420F-B16D-41D4D1F286CB@mail.lib.msu.edu>

Hi Eric,
There was a discussion about enabling a PDF view for the public on this JIRA ticket.  It sounds like the problem was that generating the PDFs would be too much of a strain on the system, but I also totally agree with you on their importance ? especially as long as the box and folder information isn?t readily available in the public interface besides clicking on each individual archival object.  https://archivesspace.atlassian.net/browse/AR-752
There is also a JIRA ticket out for simplifying the process for printing to PDFs
https://archivesspace.atlassian.net/browse/AS-46
At MSU, we?ve also used volunteers some student assistants for basic data entry.  I created a JIRA ticket for the potential to link staff profiles to collections for collection-specific permissions
https://archivesspace.atlassian.net/browse/AS-117?filter=-2
If folks are able to report or vote on JIRA issues, that helps indicate the level of interest in particular issues and also articulates better to developers what changes to implement.
Also, I have a question for you all.  I was so smug of myself to figure out how to create an autopopulated template of common fields in the finding aids.  However, somehow I can?t navigate back to that area to alter this template.  I think I?ve checked everywhere, including ?User Preference Defaults? (where I would expect), but although there is a box to check for pre-populating fields, I am not seeing where I can edit my saved fields.  I may have set this up in v. 1.4. but now we?re in 1.5.1 (and still unable to upgrade because of a weird indexing issue?.)
Thanks for your help, everyone!
Lydia
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Eric Milenkiewicz <eric.milenkiewicz at ucr.edu>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Tuesday, March 7, 2017 at 3:22 PM
To: "archivesspace_users_group at lyralists.lyrasis.org" <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Export options for User Permission Groups?

Hi All,

We have provided reference staff with Viewer access to our ASpace instance (1.4.2), however they cannot access any of the export options namely ?Print Resource to PDF.? This would be extremely helpful in reference interactions pertaining to in-process/partially processed collections that are not yet available through the public interface. The export option does not become available until the ?Advanced Data Entry? level which provides more privileges than we would like to grant here. And exports aren?t listed as one of the Manage Groups functions that can be toggled on/off.

I?m curious to hear if others are facing similar issues and if there are any workarounds/planned improvements in this area? Thanks.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942


From sdm7g at eservices.virginia.edu  Tue Mar  7 16:20:41 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Tue, 7 Mar 2017 21:20:41 +0000
Subject: [Archivesspace_Users_Group] Limiting RAM usage by Java and AS
In-Reply-To: <403F67E7-9ADC-45D4-8792-4188F228FAE2@towson.edu>
References: <403F67E7-9ADC-45D4-8792-4188F228FAE2@towson.edu>
Message-ID: <F2E60AD6-9F86-4070-9828-703FF8C6A283@eservices.virginia.edu>


I haven?t had the need to change settings, but I believe you can set any of the java options in the archivesspace.{sh,bat} scripts. And it looks like you can also change the values with unix shell environment variables: 



if [ "$ASPACE_JAVA_XMX" = "" ]; then
    ASPACE_JAVA_XMX="-Xmx1024m"
fi

if [ "$ASPACE_JAVA_XSS" = "" ]; then
    ASPACE_JAVA_XSS="-Xss2m"
fi

if [ "$ASPACE_JAVA_MAXPERMSIZE" = "" ]; then
    ASPACE_JAVA_MAXPERMSIZE="-XX:MaxPermSize=256m"
fi




> On Mar 7, 2017, at 3:57 PM, Gadsby, Eric T. <egadsby at towson.edu> wrote:
> 
> Good afternoon. Has anybody had any experience with this? We are using the standard Jetty set up. Thanks in advance for the community?s help! 
> 
> Eric T Gadsby ? IT Operations Specialist
> 
> University Libraries <http://libraries.towson.edu>
> Towson University <http://www.towson.edu/> ? 8000 York Road ? Towson, Maryland,  21252-0001
> p. 410-704-3340
> <http://www.towson.edu/>
> 
> Confidentiality Notice: This message may contain information that is confidential, privileged, proprietary, or otherwise legally exempt from disclosure. If you are not the intended recipient, you are notified that you are not authorized to read, print, copy or disseminate this message, any part of it, or any attachments. If this message has been sent to you in error, please notify the sender by replying to this transmission, or by calling University Libraries at 410-704-3340. 
> 
> 
> 
> On 2/16/17, 3:39 PM, "archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Gadsby, Eric T." <archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of egadsby at towson.edu> wrote:
> 
>    Dear Friends,
> 
>    We our AS install is eating up a lot of RAM as Java is known to do. I know other Java based applications I have administered sometimes have ways to limit java ram usage. Is this true for AS?  If so how does one do it. Please pardon if the question asked before. Thanks! 
> 
>    Sincerely,
> 
>    Eric T Gadsby
>    IT Operations Specialist, Cook Library
>    Towson University
>    egadsby at towson.edu
>    410-704-3340
> 
>    _______________________________________________
>    Archivesspace_Users_Group mailing list
>    Archivesspace_Users_Group at lyralists.lyrasis.org
>    http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> 
> 
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group


From ljdavis at jhu.edu  Tue Mar  7 16:28:41 2017
From: ljdavis at jhu.edu (Lora Davis)
Date: Tue, 7 Mar 2017 21:28:41 +0000
Subject: [Archivesspace_Users_Group] Processors ability to delete?
In-Reply-To: <6276AE0B-B23A-4747-AC17-3ACDC684C372@eservices.virginia.edu>
References: <CY4PR01MB23121C156D279C04BE9EE218F42F0@CY4PR01MB2312.prod.exchangelabs.com>
 <CAFfoRK5nazmCizTGUdXaXdPcbzkkWGm6JEimvPBD05tujsK_hA@mail.gmail.com>
 <6276AE0B-B23A-4747-AC17-3ACDC684C372@eservices.virginia.edu>
Message-ID: <c148fde0d3f04b7da6d61c50a85999a7@ESGEBEX8.win.ad.jhu.edu>

My number one #ASpacePipeDream is for there to be some sort of workflow management functionality built-in.


-          Data entry user marks whoopsie item for deletion

-          Repo manager is notifed

-          Repo manager chooses to allow deletion or send back for review

-          Repo manager actually deletes

I say this as someone who once had a truly awesome, talented employee (at a former gig) accidentally delete an entire resource record.  (Though, this fix has made that far less likely https://archivesspace.atlassian.net/browse/AR-1313)

Lora


Lora J. Davis
Digital Archivist
The Sheridan Libraries
Johns Hopkins University
3400 North Charles Street
Baltimore, MD     21228
(410) 516-5898
ljdavis at jhu.edu



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g)
Sent: Tuesday, March 07, 2017 4:10 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Processors ability to delete?


We?ve also run into this where people can create a resource, but can?t delete it if they make a mistake and want to start over, or just want to create a test object when learning.  But in general, I think it?s a good idea to make deleting a record more privileged. Maybe a useful feature would be to make the permission behavior dependent on resource status - perhaps make only published items require elevated permission to delete, or else make a exception for ?draft? status or some other value.


On Mar 7, 2017, at 3:58 PM, Lisa Calahan <lcalahan at umn.edu<mailto:lcalahan at umn.edu>> wrote:

Hi Eric,

We have also run into this issue. It would be a great feature if the deletion of component records could be a separate permission from the "delete all major record types in this repository."

We have a couple of workarounds that we've used, none of which are really sustainable. 1) A student/staff person will report when they need a component record deleted and a staff person with that permission will delete the record for them (usually happens when a component record was accidentally duplicated) and a supervisor is sitting close by. 2) The repository manager or ASpace administrator will temporarily give the permission group "delete the major record types of this repository" permission to be able to delete; which is paired with a stern talking to about being careful to not delete a resource record. 3) Move multiple/various component records that need to be deleted into a "To delete" grouping/fake series at the end of the resource record to have a supervisor delete as one of the final review tasks.

Best,
Lisa

On Tue, Mar 7, 2017 at 2:35 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<mailto:eric.milenkiewicz at ucr.edu>> wrote:
Hi All,

We have recently hired/trained student employees on processing archival collections in ASpace, however we cannot seem to find a way of fine tuning the user permission groups to provide them with an appropriate level of access.

For example, the advanced/basic data entry staff and archivist levels do not allow permissions for resource component records to be deleted (which is often times needed while processing, as things change). This level of access is not achieved until the repository/project manager level which provides much greater permissions. Configuring the User Permission Groups also has not helped here since once the ?delete the major record types in this repository? option is checked then entire Resource and Accession records can be deleted (a function we want to restrict to higher level staff).

Has anyone else run into this type of permissions issue? And if so, have you identified any workarounds?

Thanks,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942<tel:(951)%20827-4942>


_______________________________________________
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



--

Head of Archival Processing

University of Minnesota Libraries
Archives and Special Collections
Elmer L. Andersen Library, Suite 315
222-21st Ave. S.
Minneapolis MN 55455

Phone: 612.626.2531
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/044b2c71/attachment.html>

From sdm7g at eservices.virginia.edu  Tue Mar  7 16:37:31 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Tue, 7 Mar 2017 21:37:31 +0000
Subject: [Archivesspace_Users_Group] Export options for
	User	Permission	Groups?
In-Reply-To: <D19993AF-84F9-4875-B43F-3AEC7D6F5DE6@eservices.virginia.edu>
References: <CY4PR01MB2312978C97A464D78BF16206F42F0@CY4PR01MB2312.prod.exchangelabs.com>
 <D19993AF-84F9-4875-B43F-3AEC7D6F5DE6@eservices.virginia.edu>
Message-ID: <7250E9B5-FDFC-4815-8DDB-EE3E5F5D14CC@eservices.virginia.edu>


Note: I tried this with current version. Not sure if it will work the same on 1.4.2.


On Mar 7, 2017, at 4:04 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:


I believe if you add ?initiate import jobs? permission to the group, although the option will not show up when viewing the resource, you can click on "Create/Background Jobs? menu and download a PDF that way. However that?s probably still granting more permissions than you want. I believe that now that there are other types of batch jobs, ?import? applies to all batch jobs. Yes: it?s often difficult to figure out what permission you need to turn on for a particular use case. Another alternative is to enable the aspace-public-formats plugin and then you can download PDF from the public web server.


In general: Yes ? I?ve had problems with the ArchivesSpace permissions system. In some places it doesn?t grant even read permission to things that you don?t have permission to change. I believe that?s the case for repository information.  I know there are more ? I?m sorry I haven?t been keeping a list of the issues as they come up. Another issue is that users can?t change their own passwords ? they need an admin to set them.

? Steve.



On Mar 7, 2017, at 3:30 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<mailto:eric.milenkiewicz at ucr.edu>> wrote:

Hi All,

We have provided reference staff with Viewer access to our ASpace instance (1.4.2), however they cannot access any of the export options namely ?Print Resource to PDF.? This would be extremely helpful in reference interactions pertaining to in-process/partially processed collections that are not yet available through the public interface. The export option does not become available until the ?Advanced Data Entry? level which provides more privileges than we would like to grant here. And exports aren?t listed as one of the Manage Groups functions that can be toggled on/off.

I?m curious to hear if others are facing similar issues and if there are any workarounds/planned improvements in this area? Thanks.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942

_______________________________________________
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

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/73eb7940/attachment.html>

From Tony.Kurtz at wwu.edu  Tue Mar  7 18:13:59 2017
From: Tony.Kurtz at wwu.edu (Tony Kurtz)
Date: Tue, 7 Mar 2017 23:13:59 +0000
Subject: [Archivesspace_Users_Group] Top containers as box-folder
In-Reply-To: <BE7C2AB4-C39F-46FD-93FF-178A4DCFFEF0@eservices.virginia.edu>
References: <DM5PR02MB242807BE3E19FAB331234C20952C0@DM5PR02MB2428.namprd02.prod.outlook.com>
 <BE7C2AB4-C39F-46FD-93FF-178A4DCFFEF0@eservices.virginia.edu>
Message-ID: <DM5PR02MB2428642D0858D9A526107FD6952F0@DM5PR02MB2428.namprd02.prod.outlook.com>

Many thanks, Steve.  We had already set up a test database to try something like this, so it?s good to confirm that approach based on your experience!

TK



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g)
Sent: Monday, March 06, 2017 10:41 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Top containers as box-folder


We had this problem as well. See previous thread in mailing list:

http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2016-November/004238.html


I believe it?s a lot easier to fix the problem in 1.4.2 before migration, where it can be done in MySQL, than to try to fix it afterwards when top_container become independent linked objects: a lot simpler to just change a couple values in a table than to deal with deleting and creating top_containers.

In our case it was a bit more complicated because some of the container type enums had already been merged and changed, so it required pulling info from a previous mysqldump and creating a view over several tables.
In your case, I think you can just lookup the container type ids for ?box?, ?folder? and ?box/folder? and update the container values where type_1_id = [box/folder id] AND type_2_id IS NULL and indicator_1 LIKE ?%/%? and indicator_2 is NULL.


You might want to first do some exploring of table values in MySQL to check that there aren?t any false positives. I also tested everything out on a local test server with a database cloned from mysqldump of production database, before trying the procedure on production data.


? Steve.


On Mar 6, 2017, at 12:53 PM, Tony Kurtz <Tony.Kurtz at wwu.edu<mailto:Tony.Kurtz at wwu.edu>> wrote:

Greetings,
I?ve searched around but I don?t think I?ve been able to find an answer to an issue we?re having.  If I?m mistaken I?ll happily endure the embarrassment along with the solution!

We are planning an upgrade from AS 1.4.2 to 1.5 and we are doing an assessment of how our top containers will look post-upgrade.  One of our repositories expresses almost all containers with a type indicator of ?box-folder? and a value expressed as a box/folder pair, e.g. ?1/1?, ?1/2?, etc. (and all box/folder expressions are unique within a collection?i.e., each ?b/f? value is not repeated). From what we can tell, it looks like the 1.5 upgrade process will result in top containers being created at the folder level.  However, we want top containers to be at the box level.  Is our assumption correct that top containers will be created as folders?  Does anyone have advice on how best to navigate this so that we can ensure that boxes are our top containers?e.g. is there anything we can do prior to the upgrade to make this work out as we wish, or will we just need to do the work post-ugrade?

Thanks

Tony Kurtz
Western Washington University
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/e65f576b/attachment.html>

From livsolis at utexas.edu  Tue Mar  7 19:02:07 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Tue, 7 Mar 2017 18:02:07 -0600
Subject: [Archivesspace_Users_Group] Former users and data loss
Message-ID: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been
testing it out in a sandbox. We took note of a potential problem in the
future regarding hypothetical former employees who may have been ASpace
users at one point. Presumably, we would delete them after they moved on to
other work. I wanted to see what a user's trail might look like after
he/she were deleted from the system, so I created an appraisal event with a
user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is
retained, in some fields it is not. For instance:

   - In the Events Browser, the former employee/user appears as the
   authorizer and record creator
   - Within the event itself, the agent link is blank
   - In the resource record the event is linked to, the agent links field
   is empty, but the created and Last modified fields list the now deleted user

Before you delete an agent record, ArchivesSpace does warn you that you
will lose all references to it in the database, including references to it
in other records. How have some of you anticipated handling this situation?
Leave former employees in the system and change their passwords? Is there a
workaround for some of the loss of data or am I missing an obvious solution
to this?

Thanks!
Olivia

-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/b49e8f09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Event Record Fields.png
Type: image/png
Size: 24346 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/b49e8f09/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Event in Browse Events.png
Type: image/png
Size: 25052 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/b49e8f09/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Linked Event in Resource Record.png
Type: image/png
Size: 41223 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170307/b49e8f09/attachment-0002.png>

From sustasiula at pa.gov  Wed Mar  8 08:42:37 2017
From: sustasiula at pa.gov (Stasiulatis, Suzanne)
Date: Wed, 8 Mar 2017 13:42:37 +0000
Subject: [Archivesspace_Users_Group] Archon to ArchivesSpace Migration Issues
Message-ID: <9a5d2d912a694330a2306731a644cd5e@ENCTCEXCH008.PA.LCL>

Hello,

We have two major problems with our migration from Archon to ArchivesSpace. Any help is appreciated. We did not have success with the migration from Archon to 1.4.2. We moved to 1.0.4 to 1.4.2 to 1.5.2. The migration and upgrade complete but we have two major problems.

There are no top container drop downs in the component tree. The top containers are there, but they are not appearing as expected with drop downs in the component tree or in the staff interface.

A large portion of our component data is scrambled. Some of the components are perfectly fine. They are in order and match the Archon listing line for line. Other listings (about 1/3 to ?) are out of order. Often the components are in order within a container, but out of order otherwise. Other listings have components out of order. We've searched for a pattern but not found one. The scrambling seems to be totally random.

Thanks in advance!

Suzanne

Suzanne Stasiulatis | Archivist II
Pennsylvania Historical and Museum Commission | Pennsylvania State Archives
350 North Street | Harrisburg, PA 17120-0090
Phone: 717-787-5953
http://www.phmc.pa.gov<http://www.phmc.pa.gov/>
sustasiula at pa.gov<mailto:sustasiula at pa.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/69c917ac/attachment.html>

From bthomas at tsl.texas.gov  Wed Mar  8 09:44:36 2017
From: bthomas at tsl.texas.gov (Brian Thomas)
Date: Wed, 8 Mar 2017 14:44:36 +0000
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
Message-ID: <CY4PR1601MB1349155F9F828EFCFF999AA6FA2E0@CY4PR1601MB1349.namprd16.prod.outlook.com>

I haven?t come across this problem as yet (still working out implementation issues), but have you tried creating a dummy agent record for your defunct user, merging your actual user with said dummy user, then deleting the user info from the system? There is a similar situation with some flavors of drupal/wordpress and the workaround for that is to modify the user info such that the previous employee has no way of logging in, such as changing the login email address/password.

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Tuesday, March 07, 2017 6:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Former users and data loss

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been testing it out in a sandbox. We took note of a potential problem in the future regarding hypothetical former employees who may have been ASpace users at one point. Presumably, we would delete them after they moved on to other work. I wanted to see what a user's trail might look like after he/she were deleted from the system, so I created an appraisal event with a user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is retained, in some fields it is not. For instance:

  *   In the Events Browser, the former employee/user appears as the authorizer and record creator
  *   Within the event itself, the agent link is blank
  *   In the resource record the event is linked to, the agent links field is empty, but the created and Last modified fields list the now deleted user
Before you delete an agent record, ArchivesSpace does warn you that you will lose all references to it in the database, including references to it in other records. How have some of you anticipated handling this situation? Leave former employees in the system and change their passwords? Is there a workaround for some of the loss of data or am I missing an obvious solution to this?

Thanks!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu<mailto:livsolis at utexas.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/738c825e/attachment.html>

From trthorn2 at ncsu.edu  Wed Mar  8 10:07:41 2017
From: trthorn2 at ncsu.edu (Trevor Thornton)
Date: Wed, 8 Mar 2017 10:07:41 -0500
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
Message-ID: <CA+SdyS1L_adJ1jXq-bLM1DEZ83qxANP0LYiVj9GtAL=NQakKmg@mail.gmail.com>

I would think that removing the user from all groups (so that they can't do
anything) and changing the password (so that they can't log in anyway)
should do the trick. In this way the user will effectively be 'inactive'
but will remain in the system as an agent.

On Tue, Mar 7, 2017 at 7:02 PM, Olivia S Solis <livsolis at utexas.edu> wrote:

> Hello all,
>
> The Briscoe Center is in the process of adopting ArchivesSpace and has
> been testing it out in a sandbox. We took note of a potential problem in
> the future regarding hypothetical former employees who may have been ASpace
> users at one point. Presumably, we would delete them after they moved on to
> other work. I wanted to see what a user's trail might look like after
> he/she were deleted from the system, so I created an appraisal event with a
> user (my dog Chicken) as the authorizer.
>
> The results are mixed. While in some fields it looks like the data is
> retained, in some fields it is not. For instance:
>
>    - In the Events Browser, the former employee/user appears as the
>    authorizer and record creator
>    - Within the event itself, the agent link is blank
>    - In the resource record the event is linked to, the agent links field
>    is empty, but the created and Last modified fields list the now deleted user
>
> Before you delete an agent record, ArchivesSpace does warn you that you
> will lose all references to it in the database, including references to it
> in other records. How have some of you anticipated handling this situation?
> Leave former employees in the system and change their passwords? Is there a
> workaround for some of the loss of data or am I missing an obvious solution
> to this?
>
> Thanks!
> Olivia
>
> --
> Olivia Solis, MSIS
> Metadata Coordinator
> Dolph Briscoe Center for American History
> The University of Texas at Austin
> 2300 Red River St. Stop D1100
> Austin TX, 78712-1426
> livsolis at utexas.edu
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/05f52e29/attachment.html>

From mary.caldera at yale.edu  Wed Mar  8 10:24:13 2017
From: mary.caldera at yale.edu (Caldera, Mary)
Date: Wed, 8 Mar 2017 15:24:13 +0000
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
Message-ID: <CY1PR08MB131132251721149045814158E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>

Hi,

Our Yale ArchivesSpace User management Policy, prohibits the deletion of user records for the very reasons noted. The relevant section is as follows. ?

Access Control
?         The creation, deactivation, and the changing of user accounts and privileges must be carried out only by trained and authorized staff (i.e. the Yale ArchivesSpace Committee).
?         Access to ArchivesSpace will be limited to the Yale NetIDs of people who are members of the ArchivesSpace Active Group. This single Active Group will have access to all three instances of ArchivesSpace at Yale: dev, production, and test. Even though access will be allowed to the same three instances, that does not mean that each will have the same set of privileges. For example, only developers will have privileges in the dev instance.
?         The person enacting any change to a user account must be different from the person requesting the change.
?         Accounts should never be deleted from the ArchivesSpace database; instead, when a user no longer requires access to the ArchivesSpace database, their account will be deactivated.
?         Accounts will be deactivated by following these three steps:
o    The ArchivesSpace username will be preceded with a ?zzz_? in the ArchivesSpace database.
o    The Yale NetID will be removed from the ArchivesSpace Active Directory group.
o    Any repository roles associated with that account will be removed.
?         Inactive accounts will be periodically reviewed to determine if any need to be deactivated.
?         Accounts may be re-activated -- but only after a request has been issued and approved by following the same procedures required for requesting a new account -- by removing the ?zzz_? from an existing username and then following the same procedure for the addition of any new ArchivesSpace account.
Sincerely,
Mary
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Tuesday, March 7, 2017 7:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Former users and data loss

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been testing it out in a sandbox. We took note of a potential problem in the future regarding hypothetical former employees who may have been ASpace users at one point. Presumably, we would delete them after they moved on to other work. I wanted to see what a user's trail might look like after he/she were deleted from the system, so I created an appraisal event with a user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is retained, in some fields it is not. For instance:

  *   In the Events Browser, the former employee/user appears as the authorizer and record creator
  *   Within the event itself, the agent link is blank
  *   In the resource record the event is linked to, the agent links field is empty, but the created and Last modified fields list the now deleted user
Before you delete an agent record, ArchivesSpace does warn you that you will lose all references to it in the database, including references to it in other records. How have some of you anticipated handling this situation? Leave former employees in the system and change their passwords? Is there a workaround for some of the loss of data or am I missing an obvious solution to this?

Thanks!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu<mailto:livsolis at utexas.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/f748f062/attachment.html>

From sdm7g at eservices.virginia.edu  Wed Mar  8 10:32:31 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 8 Mar 2017 15:32:31 +0000
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <CY1PR08MB131132251721149045814158E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
 <CY1PR08MB131132251721149045814158E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
Message-ID: <45F0B491-6648-453A-957B-30FE645AF23C@eservices.virginia.edu>


It appears to be a misfeature that deleting a user also deletes the agent record for that user, which is what the backend model for user does.

I believe removing those last three lines would fix the problem:
https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/user.rb#L244-L246

i.e. remove the User object but leave the Agent object. Links are from User to Agent, so I don?t think there would be any unexpected side effects. As a test, I removed a User record only on a test site in MySQL, and display still shows their id as the author.

I will test this further if there is a consensus that this is the desired behavior.

? Steve.


On Mar 8, 2017, at 10:24 AM, Caldera, Mary <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>> wrote:

Hi,

Our Yale ArchivesSpace User management Policy, prohibits the deletion of user records for the very reasons noted. The relevant section is as follows. ?

Access Control
?         The creation, deactivation, and the changing of user accounts and privileges must be carried out only by trained and authorized staff (i.e. the Yale ArchivesSpace Committee).
?         Access to ArchivesSpace will be limited to the Yale NetIDs of people who are members of the ArchivesSpace Active Group. This single Active Group will have access to all three instances of ArchivesSpace at Yale: dev, production, and test. Even though access will be allowed to the same three instances, that does not mean that each will have the same set of privileges. For example, only developers will have privileges in the dev instance.
?         The person enacting any change to a user account must be different from the person requesting the change.
?         Accounts should never be deleted from the ArchivesSpace database; instead, when a user no longer requires access to the ArchivesSpace database, their account will be deactivated.
?         Accounts will be deactivated by following these three steps:
o    The ArchivesSpace username will be preceded with a ?zzz_? in the ArchivesSpace database.
o    The Yale NetID will be removed from the ArchivesSpace Active Directory group.
o    Any repository roles associated with that account will be removed.
?         Inactive accounts will be periodically reviewed to determine if any need to be deactivated.
?         Accounts may be re-activated -- but only after a request has been issued and approved by following the same procedures required for requesting a new account -- by removing the ?zzz_? from an existing username and then following the same procedure for the addition of any new ArchivesSpace account.
Sincerely,
Mary
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org]On Behalf Of Olivia S Solis
Sent: Tuesday, March 7, 2017 7:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Former users and data loss

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been testing it out in a sandbox. We took note of a potential problem in the future regarding hypothetical former employees who may have been ASpace users at one point. Presumably, we would delete them after they moved on to other work. I wanted to see what a user's trail might look like after he/she were deleted from the system, so I created an appraisal event with a user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is retained, in some fields it is not. For instance:

  *   In the Events Browser, the former employee/user appears as the authorizer and record creator
  *   Within the event itself, the agent link is blank
  *   In the resource record the event is linked to, the agent links field is empty, but the created and Last modified fields list the now deleted user

Before you delete an agent record, ArchivesSpace does warn you that you will lose all references to it in the database, including references to it in other records. How have some of you anticipated handling this situation? Leave former employees in the system and change their passwords? Is there a workaround for some of the loss of data or am I missing an obvious solution to this?

Thanks!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu<mailto:livsolis at utexas.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/a82b9299/attachment.html>

From sdm7g at eservices.virginia.edu  Wed Mar  8 10:38:29 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 8 Mar 2017 15:38:29 +0000
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <45F0B491-6648-453A-957B-30FE645AF23C@eservices.virginia.edu>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
 <CY1PR08MB131132251721149045814158E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
 <45F0B491-6648-453A-957B-30FE645AF23C@eservices.virginia.edu>
Message-ID: <E283FE9E-FF0B-4BEB-AAB9-86DEAA96F70A@eservices.virginia.edu>


On Mar 8, 2017, at 10:32 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:


It appears to be a misfeature that deleting a user also deletes the agent record for that user, which is what the backend model for user does.

I believe removing those last three lines would fix the problem:
https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/user.rb#L244-L246

i.e. remove the User object but leave the Agent object. Links are from User to Agent, so I don?t think there would be any unexpected side effects. As a test, I removed a User record only on a test site in MySQL, and display still shows their id as the author.

I will test this further if there is a consensus that this is the desired behavior.


Downside of this method is that a lot of the organizational info for the person like title and department is attached to that User record, and that would be handy to know for the Audit.

So perhaps everyone should follow Yale?s guide and NOT delete users, but this might still be a good code change to prevent complete loss of the trail in case someone does delete a User.



? Steve.


On Mar 8, 2017, at 10:24 AM, Caldera, Mary <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>> wrote:

Hi,

Our Yale ArchivesSpace User management Policy, prohibits the deletion of user records for the very reasons noted. The relevant section is as follows. ?

Access Control
?         The creation, deactivation, and the changing of user accounts and privileges must be carried out only by trained and authorized staff (i.e. the Yale ArchivesSpace Committee).
?         Access to ArchivesSpace will be limited to the Yale NetIDs of people who are members of the ArchivesSpace Active Group. This single Active Group will have access to all three instances of ArchivesSpace at Yale: dev, production, and test. Even though access will be allowed to the same three instances, that does not mean that each will have the same set of privileges. For example, only developers will have privileges in the dev instance.
?         The person enacting any change to a user account must be different from the person requesting the change.
?         Accounts should never be deleted from the ArchivesSpace database; instead, when a user no longer requires access to the ArchivesSpace database, their account will be deactivated.
?         Accounts will be deactivated by following these three steps:
o    The ArchivesSpace username will be preceded with a ?zzz_? in the ArchivesSpace database.
o    The Yale NetID will be removed from the ArchivesSpace Active Directory group.
o    Any repository roles associated with that account will be removed.
?         Inactive accounts will be periodically reviewed to determine if any need to be deactivated.
?         Accounts may be re-activated -- but only after a request has been issued and approved by following the same procedures required for requesting a new account -- by removing the ?zzz_? from an existing username and then following the same procedure for the addition of any new ArchivesSpace account.
Sincerely,
Mary
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org]On Behalf Of Olivia S Solis
Sent: Tuesday, March 7, 2017 7:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Former users and data loss

Hello all,

The Briscoe Center is in the process of adopting ArchivesSpace and has been testing it out in a sandbox. We took note of a potential problem in the future regarding hypothetical former employees who may have been ASpace users at one point. Presumably, we would delete them after they moved on to other work. I wanted to see what a user's trail might look like after he/she were deleted from the system, so I created an appraisal event with a user (my dog Chicken) as the authorizer.

The results are mixed. While in some fields it looks like the data is retained, in some fields it is not. For instance:

  *   In the Events Browser, the former employee/user appears as the authorizer and record creator
  *   Within the event itself, the agent link is blank
  *   In the resource record the event is linked to, the agent links field is empty, but the created and Last modified fields list the now deleted user

Before you delete an agent record, ArchivesSpace does warn you that you will lose all references to it in the database, including references to it in other records. How have some of you anticipated handling this situation? Leave former employees in the system and change their passwords? Is there a workaround for some of the loss of data or am I missing an obvious solution to this?

Thanks!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu<mailto:livsolis at utexas.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

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/5b2c6976/attachment.html>

From k-miller3 at northwestern.edu  Wed Mar  8 11:02:56 2017
From: k-miller3 at northwestern.edu (Karen Miller)
Date: Wed, 8 Mar 2017 16:02:56 +0000
Subject: [Archivesspace_Users_Group] Archon to ArchivesSpace Migration
	Issues
In-Reply-To: <9a5d2d912a694330a2306731a644cd5e@ENCTCEXCH008.PA.LCL>
References: <9a5d2d912a694330a2306731a644cd5e@ENCTCEXCH008.PA.LCL>
Message-ID: <bd3b450e986b48f1b47a7197c1155b40@evcspmbx05.ads.northwestern.edu>

Hi, Suzanne.

We migrated from Archon to ArchivesSpace 1.4.2 in December at Northwestern University. We did not experience issues with top containers, but we did have about 2 dozen (out of 1200+) finding aids come over with scrambled components.

As you described, the scrambling appeared to be completely random. When I looked at records in the Archon MySQL database for a few of the scrambled components, I found some components with parent relationships that formed a circle - for example, the parent ID values of records indicated that component A had component B as parent, component B had component C as parent, and component C had component A as parent. We think that was due to people moving around the components in the Archon interface, or that it might have had to do with a flawed ingest into Archon from the original EAD. Some of these components did not appear in the Archon interface, only in the MySQL database.

For the "scrambled" finding aids, I exported these as EAD from Archon and then used the Background Job -> Import Data to ingest them into ArchivesSpace. This is not without its own drama. Ingesting from EAD this way has a few bugs:


?        Agent & Subject records will come in as Unpublished (this might be rectified if you set the Publish? checkbox defaults to be checked in User Preferences, but I'm not sure about that).

?        Ampersands display in ArchivesSpace as character entities (&amp;) instead of as ampersands.

?        Any <note> elements attached to a component (Archival Object) record did not ingest at all. <note> elements at the Resource record did ingest, so this is only a problem for really detailed finding aids.

To make the ingest work, you'll need to add the <extent> type attribute into the value for the <extent> element at the archival description level. That is, under <archdesc>, change the line that looks like this:

<physdesc label="Physical Description">
<extent encodinganalog="300" type="Boxes">121</extent>

to this:

<physdesc label="Physical Description">
<extent encodinganalog="300" type="Boxes">121 Boxes</extent>

You'll also want to change the value of the <eadid> value to something that differentiates it from the <eadid> value for the existing resource record in ArchivesSpace. I added "-TEST" to the end of mine so that I could differentiate them in ArchivesSpace.

Finally, you might run into errors because of components that lack a <unittitle> and a <unitdate> during the ingest. You can fix these and then reingest the finding aid, but this can get a little tedious because the ingest only identifies the first one it runs into and then fails. (So if you have 5 components that cause it errors, you'll have to try the ingest 6 times to get it in there). Interpreting the errors is tedious, but it can be done. They will look like this:

The following errors were found:
        dates : one or more required (or enter a Title)
        title : must not be an empty string (or enter a Date)


For JSONModel(:archival_object):
 #<JSONModel(:archival_object) {"jsonmodel_type"=>"archival_object", "external_ids"=>[], "subjects"=>[], "linked_events"=>[], "extents"=>[], "dates"=>[], "external_documents"=>[], "rights_statements"=>[], "linked_agents"=>[], "component_id"=>"id113570", "restrictions_apply"=>false, "instances"=>[{"jsonmodel_type"=>"instance", "is_representative"=>false, "uri"=>nil, "import_context"=>"<container class=\"cdata\" type=\"Box\"> ... </container>", "instance_type"=>"mixed_materials", "container"=>{"jsonmodel_type"=>"container", "container_locations"=>[], "uri"=>nil, "import_context"=>"<container class=\"cdata\" type=\"Box\"> ... </container>", "container_profile_key"=>nil, "type_1"=>"Box", "indicator_1"=>"89", "type_2"=>"Folder", "indicator_2"=>"1", "type_3"=>"Sleeve", "indicator_3"=>"24"}}], "notes"=>[], "uri"=>"/repositories/import/archival_objects/import_544f0225-8313-4396-9c17-0ed8075640fc", "level"=>"file", "resource"=>{"ref"=>"/repositories/import/resources/import_73c30f1d-c9e2-444b-b482-84a380ee8f1a"}, "parent"=>{"ref"=>"/repositories/import/archival_objects/import_be1e2fd1-38d2-4550-be86-efdd88070162"}, "publish"=>true}>


In :
 &lt;c03 audience=&quot;external&quot; class=&quot;cdata&quot; level=&quot;file&quot;&gt; ... &lt;/c03&gt;


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

This one means that a component with container elements representing Box 89, Folder 1, and Sleeve 24 (bolding & font color above are mine and I hope they come through the listserv) has neither a <unittitle> nor a <unitdate>.

I hope this is helpful. This worked really well for our smaller finding aids, but it wasn't ideal for a handful of large ones for us. Still, it was better than trying to unscramble the components in ArchivesSpace.

Karen


Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu
k-miller3 at northwestern.edu
874.467.3462

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Stasiulatis, Suzanne
Sent: Wednesday, March 08, 2017 7:43 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Archon to ArchivesSpace Migration Issues

Hello,

We have two major problems with our migration from Archon to ArchivesSpace. Any help is appreciated. We did not have success with the migration from Archon to 1.4.2. We moved to 1.0.4 to 1.4.2 to 1.5.2. The migration and upgrade complete but we have two major problems.

There are no top container drop downs in the component tree. The top containers are there, but they are not appearing as expected with drop downs in the component tree or in the staff interface.

A large portion of our component data is scrambled. Some of the components are perfectly fine. They are in order and match the Archon listing line for line. Other listings (about 1/3 to ?) are out of order. Often the components are in order within a container, but out of order otherwise. Other listings have components out of order. We've searched for a pattern but not found one. The scrambling seems to be totally random.

Thanks in advance!

Suzanne

Suzanne Stasiulatis | Archivist II
Pennsylvania Historical and Museum Commission | Pennsylvania State Archives
350 North Street | Harrisburg, PA 17120-0090
Phone: 717-787-5953
http://www.phmc.pa.gov<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phmc.pa.gov_&d=CwMFAw&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ&m=6l7pcX_DRoO3WDrM3UVIW_dUQy5XDnwCyQqCWS6brZ4&s=37d1H2sjeBYbYn-9kBvzcgmiwkexfB5gqsAWqtLQBEw&e=>
sustasiula at pa.gov<mailto:sustasiula at pa.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/10676721/attachment.html>

From livsolis at utexas.edu  Wed Mar  8 11:36:12 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Wed, 8 Mar 2017 10:36:12 -0600
Subject: [Archivesspace_Users_Group] Former users and data loss
In-Reply-To: <E283FE9E-FF0B-4BEB-AAB9-86DEAA96F70A@eservices.virginia.edu>
References: <CAKu+i=2qVN057gxEMcyaD5HefsbEGSOngdWDgBsjp_TX59j9rg@mail.gmail.com>
 <CY1PR08MB131132251721149045814158E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
 <45F0B491-6648-453A-957B-30FE645AF23C@eservices.virginia.edu>
 <E283FE9E-FF0B-4BEB-AAB9-86DEAA96F70A@eservices.virginia.edu>
Message-ID: <CAKu+i=0hiiUNjgROoBMw7dQ94-an4=21rjP7B_7PrAacK7MmnQ@mail.gmail.com>

Thank you all for this useful information! The policy language is
particularly helpful.

Best,
Olivia

On Wed, Mar 8, 2017 at 9:38 AM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu> wrote:

>
> On Mar 8, 2017, at 10:32 AM, Majewski, Steven Dennis (sdm7g) <
> sdm7g at eservices.virginia.edu> wrote:
>
>
> It appears to be a misfeature that deleting a user also deletes the agent
> record for that user, which is what the backend model for user does.
>
> I believe removing those last three lines would fix the problem:
> https://github.com/archivesspace/archivesspace/
> blob/master/backend/app/model/user.rb#L244-L246
>
> i.e. remove the User object but leave the Agent object. Links are from
> User to Agent, so I don?t think there would be any unexpected side effects.
> As a test, I removed a User record only on a test site in MySQL, and
> display still shows their id as the author.
>
> I will test this further if there is a consensus that this is the desired
> behavior.
>
>
> Downside of this method is that a lot of the organizational info for the
> person like title and department is attached to that User record, and that
> would be handy to know for the Audit.
>
> So perhaps everyone should follow Yale?s guide and NOT delete users, but
> this might still be a good code change to prevent complete loss of the
> trail in case someone does delete a User.
>
>
>
> ? Steve.
>
>
> On Mar 8, 2017, at 10:24 AM, Caldera, Mary <mary.caldera at yale.edu> wrote:
>
> Hi,
>
> Our Yale ArchivesSpace User management Policy, prohibits the deletion of
> user records for the very reasons noted. The relevant section is as
> follows. ?
>
> *Access Control*
> ?         The creation, deactivation, and the changing of user accounts
> and privileges must be carried out only by trained and authorized staff
> (i.e. the Yale ArchivesSpace Committee).
> ?         Access to ArchivesSpace will be limited to the Yale NetIDs of
> people who are members of the ArchivesSpace Active Group. This single
> Active Group will have access to all three instances of ArchivesSpace at
> Yale: dev, production, and test. Even though access will be allowed to the
> same three instances, that does not mean that each will have the same set
> of privileges. For example, only developers will have privileges in the dev
> instance.
> ?         The person enacting any change to a user account must be
> different from the person requesting the change.
> ?         Accounts should never be deleted from the ArchivesSpace
> database; instead, when a user no longer requires access to the
> ArchivesSpace database, their account will be deactivated.
> ?         Accounts will be deactivated by following these three steps:
> o    The ArchivesSpace username will be preceded with a ?zzz_? in the
> ArchivesSpace database.
> o    The Yale NetID will be removed from the ArchivesSpace Active
> Directory group.
> o    Any repository roles associated with that account will be removed.
> ?         Inactive accounts will be periodically reviewed to determine if
> any need to be deactivated.
> ?         Accounts may be re-activated -- but only after a request has
> been issued and approved by following the same procedures required for
> requesting a new account -- by removing the ?zzz_? from an existing
> username and then following the same procedure for the addition of any new
> ArchivesSpace account.
> Sincerely,
> Mary
> _______________________________
> ________________________________
>
> Mary Caldera,
> Head of Arrangement and Description
> Manuscripts and Archives
> Yale University Library
> P.O. Box 208240
> New Haven, CT  06520-8240
> 203/432-8019 <(203)%20432-8019>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>]*On Behalf Of *Olivia
> S Solis
> *Sent:* Tuesday, March 7, 2017 7:02 PM
> *To:* archivesspace_users_group at lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] Former users and data loss
>
> Hello all,
>
> The Briscoe Center is in the process of adopting ArchivesSpace and has
> been testing it out in a sandbox. We took note of a potential problem in
> the future regarding hypothetical former employees who may have been ASpace
> users at one point. Presumably, we would delete them after they moved on to
> other work. I wanted to see what a user's trail might look like after
> he/she were deleted from the system, so I created an appraisal event with a
> user (my dog Chicken) as the authorizer.
>
> The results are mixed. While in some fields it looks like the data is
> retained, in some fields it is not. For instance:
>
>    - In the Events Browser, the former employee/user appears as the
>    authorizer and record creator
>    - Within the event itself, the agent link is blank
>    - In the resource record the event is linked to, the agent links field
>    is empty, but the created and Last modified fields list the now deleted user
>
> Before you delete an agent record, ArchivesSpace does warn you that you
> will lose all references to it in the database, including references to it
> in other records. How have some of you anticipated handling this situation?
> Leave former employees in the system and change their passwords? Is there a
> workaround for some of the loss of data or am I missing an obvious solution
> to this?
>
> Thanks!
> Olivia
>
> --
> Olivia Solis, MSIS
> Metadata Coordinator
> Dolph Briscoe Center for American History
> The University of Texas at Austin
> 2300 Red River St. Stop D1100
> Austin TX, 78712-1426
> livsolis at utexas.edu
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426

415-314-0831 <(415)%20314-0831>
livsolis at utexas.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/96143a55/attachment.html>

From livsolis at utexas.edu  Wed Mar  8 12:45:46 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Wed, 8 Mar 2017 11:45:46 -0600
Subject: [Archivesspace_Users_Group] Events subrecord quirk
Message-ID: <CAKu+i=3=P2u=DswM1+tqiXQNGpCG6Q2S0uYwnoP7yOgZk_RKHQ@mail.gmail.com>

Hello all,

In playing around with events in my institution's ArchivesSpace sandbox, I
discovered an odd quirk. I assigned a user a role in a couple of events (a
deaccession and acknowledgement_sent). When I look at the agent record for
the user, the events show up under Linked Records. However, under the
Events subrecord, ASpace displays "No records found".

While it does seem redundant to display the information twice, the Events
subrecord looks odd with the two events displayed immediately above the
label.

Thanks,
Olivia

-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
livsolis at utexas.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/421c36b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 11.25.33 AM.png
Type: image/png
Size: 169132 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/421c36b2/attachment.png>

From eric.milenkiewicz at ucr.edu  Wed Mar  8 13:49:40 2017
From: eric.milenkiewicz at ucr.edu (Eric Milenkiewicz)
Date: Wed, 8 Mar 2017 18:49:40 +0000
Subject: [Archivesspace_Users_Group] Export options for User Permission
	Groups?
Message-ID: <CY4PR01MB231254BF3C39FE8DE42764C4F42E0@CY4PR01MB2312.prod.exchangelabs.com>

Thanks Steve.

You are right, by checking the "initiate import jobs" the export functionality will be added to a User Permission Group (I verified it works in 1.4.2). As you mentioned, though, additional permissions will also be added to this user group. And navigating through the steps is also a little clunky, but it does work.

I took a look at the Public Formats plugin and it doesn't show that it was tested for compatibility past version 1.2.0, so I am not sure it will work with the later versions. That might be an option, though. Hopefully, as the product develops there will be more options for fine tuning permissions.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942

Note: I tried this with current version. Not sure if it will work the same on 1.4.2.


On Mar 7, 2017, at 4:04 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:sdm7g at eservices.virginia.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:


I believe if you add "initiate import jobs" permission to the group, although the option will not show up when viewing the resource, you can click on "Create/Background Jobs" menu and download a PDF that way. However that's probably still granting more permissions than you want. I believe that now that there are other types of batch jobs, "import" applies to all batch jobs. Yes: it's often difficult to figure out what permission you need to turn on for a particular use case. Another alternative is to enable the aspace-public-formats plugin and then you can download PDF from the public web server.


In general: Yes - I've had problems with the ArchivesSpace permissions system. In some places it doesn't grant even read permission to things that you don't have permission to change. I believe that's the case for repository information.  I know there are more - I'm sorry I haven't been keeping a list of the issues as they come up. Another issue is that users can't change their own passwords - they need an admin to set them.

- Steve.



On Mar 7, 2017, at 3:30 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:

Hi All,

We have provided reference staff with Viewer access to our ASpace instance (1.4.2), however they cannot access any of the export options namely "Print Resource to PDF." This would be extremely helpful in reference interactions pertaining to in-process/partially processed collections that are not yet available through the public interface. The export option does not become available until the "Advanced Data Entry" level which provides more privileges than we would like to grant here. And exports aren't listed as one of the Manage Groups functions that can be toggled on/off.

I'm curious to hear if others are facing similar issues and if there are any workarounds/planned improvements in this area? Thanks.

Best,

Eric Milenkiewicz
Manuscripts Curator
Special Collections & University Archives
UCR Library
951-827-4942
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/a9f676a4/attachment-0001.html>

From eric.milenkiewicz at ucr.edu  Wed Mar  8 14:01:34 2017
From: eric.milenkiewicz at ucr.edu (Eric Milenkiewicz)
Date: Wed, 8 Mar 2017 19:01:34 +0000
Subject: [Archivesspace_Users_Group] Processors ability to delete?
Message-ID: <CY4PR01MB2312576082EF045CD40FDC1DF42E0@CY4PR01MB2312.prod.exchangelabs.com>

Thanks for the feedback all and some potential workarounds. I agree that none are truly sustainable, though, in a production environment. Workflow management functionality for this would be awesome! Fingers crossed that makes it into development sometime down the line.



Best,



Eric Milenkiewicz

Manuscripts Curator

Special Collections & University Archives

UCR Library

951-827-4942





My number one #ASpacePipeDream is for there to be some sort of workflow management functionality built-in.





-          Data entry user marks whoopsie item for deletion



-          Repo manager is notifed



-          Repo manager chooses to allow deletion or send back for review



-          Repo manager actually deletes



I say this as someone who once had a truly awesome, talented employee (at a former gig) accidentally delete an entire resource record.  (Though, this fix has made that far less likely https://archivesspace.atlassian.net/browse/AR-1313)



Lora





Lora J. Davis

Digital Archivist

The Sheridan Libraries

Johns Hopkins University

3400 North Charles Street

Baltimore, MD     21228

(410) 516-5898

ljdavis at jhu.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>







From: archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>] On Behalf Of Majewski, Steven Dennis (sdm7g)

Sent: Tuesday, March 07, 2017 4:10 PM

To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>

Subject: Re: [Archivesspace_Users_Group] Processors ability to delete?





We've also run into this where people can create a resource, but can't delete it if they make a mistake and want to start over, or just want to create a test object when learning.  But in general, I think it's a good idea to make deleting a record more privileged. Maybe a useful feature would be to make the permission behavior dependent on resource status - perhaps make only published items require elevated permission to delete, or else make a exception for "draft" status or some other value.





On Mar 7, 2017, at 3:58 PM, Lisa Calahan <lcalahan at umn.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:lcalahan at umn.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:



Hi Eric,



We have also run into this issue. It would be a great feature if the deletion of component records could be a separate permission from the "delete all major record types in this repository."



We have a couple of workarounds that we've used, none of which are really sustainable. 1) A student/staff person will report when they need a component record deleted and a staff person with that permission will delete the record for them (usually happens when a component record was accidentally duplicated) and a supervisor is sitting close by. 2) The repository manager or ASpace administrator will temporarily give the permission group "delete the major record types of this repository" permission to be able to delete; which is paired with a stern talking to about being careful to not delete a resource record. 3) Move multiple/various component records that need to be deleted into a "To delete" grouping/fake series at the end of the resource record to have a supervisor delete as one of the final review tasks.



Best,

Lisa



On Tue, Mar 7, 2017 at 2:35 PM, Eric Milenkiewicz <eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:eric.milenkiewicz at ucr.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>> wrote:

Hi All,



We have recently hired/trained student employees on processing archival collections in ASpace, however we cannot seem to find a way of fine tuning the user permission groups to provide them with an appropriate level of access.



For example, the advanced/basic data entry staff and archivist levels do not allow permissions for resource component records to be deleted (which is often times needed while processing, as things change). This level of access is not achieved until the repository/project manager level which provides much greater permissions. Configuring the User Permission Groups also has not helped here since once the "delete the major record types in this repository" option is checked then entire Resource and Accession records can be deleted (a function we want to restrict to higher level staff).



Has anyone else run into this type of permissions issue? And if so, have you identified any workarounds?



Thanks,



Eric Milenkiewicz

Manuscripts Curator

Special Collections & University Archives

UCR Library

951-827-4942
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/077b0d94/attachment.html>

From kayla.skillin at boston.gov  Wed Mar  8 14:08:28 2017
From: kayla.skillin at boston.gov (Kayla Skillin)
Date: Wed, 8 Mar 2017 14:08:28 -0500
Subject: [Archivesspace_Users_Group] Report to count number of container
	types in a collection
Message-ID: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>

Hello,

At the City of Boston Archives, we recently accessioned a large record
group that contains mostly volumes. To make sure that we have an accurate
inventory of every single volume, we were wondering if there was a report
that we could run in ArchivesSpace that allows us to count these volumes?
We are putting each volume in as an item and listing it as a volume in the
top container instance so the data should be there, it's just a matter of
extracting it.

This might already exist and I just can't figure it out, but, does anyone
have any insight into this?

Thanks,
Kayla

[image: Digital_City_Seal_black.png]

Kayla Skillin

Assistant Archivist

City of Boston Archives

617.635.1195 (w)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/8a663177/attachment.html>

From sdm7g at eservices.virginia.edu  Wed Mar  8 15:26:57 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 8 Mar 2017 20:26:57 +0000
Subject: [Archivesspace_Users_Group] Report to count number of
	container	types in a collection
In-Reply-To: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>
References: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>
Message-ID: <E2D7E745-2D46-4366-BEDC-F56C3F57E19B@eservices.virginia.edu>


Does ?Download Container Labels' from the Export menu get the info you want ?  ? Steve.


On Mar 8, 2017, at 2:13 PM, Kayla Skillin <kayla.skillin at boston.gov<mailto:kayla.skillin at boston.gov>> wrote:

Hello,

At the City of Boston Archives, we recently accessioned a large record group that contains mostly volumes. To make sure that we have an accurate inventory of every single volume, we were wondering if there was a report that we could run in ArchivesSpace that allows us to count these volumes? We are putting each volume in as an item and listing it as a volume in the top container instance so the data should be there, it's just a matter of extracting it.

This might already exist and I just can't figure it out, but, does anyone have any insight into this?

Thanks,
Kayla

[Digital_City_Seal_black.png]

Kayla Skillin
Assistant Archivist
City of Boston Archives
617.635.1195 (w)


_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/56c709eb/attachment.html>

From mary.caldera at yale.edu  Wed Mar  8 15:27:31 2017
From: mary.caldera at yale.edu (Caldera, Mary)
Date: Wed, 8 Mar 2017 20:27:31 +0000
Subject: [Archivesspace_Users_Group] Report to count number of
	container	types in a collection
In-Reply-To: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>
References: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>
Message-ID: <CY1PR08MB13113260628F588349EC4FF6E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>

Hi, Kayla,

From the application, the easiest way might be to use the extent calculator at the resource level. The container types and numbers will be generated. Click Close instead of Create extent if you do not want to save the generated extant statement. Another way would be to use the Mange Containers functionality. It will list all the containers give you an count of all the containers, but not by type.

I attach a png showing the extent calculated window.
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kayla Skillin
Sent: Wednesday, March 8, 2017 2:08 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Report to count number of container types in a collection

Hello,

At the City of Boston Archives, we recently accessioned a large record group that contains mostly volumes. To make sure that we have an accurate inventory of every single volume, we were wondering if there was a report that we could run in ArchivesSpace that allows us to count these volumes? We are putting each volume in as an item and listing it as a volume in the top container instance so the data should be there, it's just a matter of extracting it.

This might already exist and I just can't figure it out, but, does anyone have any insight into this?

Thanks,
Kayla


[Digital_City_Seal_black.png]


Kayla Skillin

Assistant Archivist

City of Boston Archives

617.635.1195 (w)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/8ed9059b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extent calculation.png
Type: image/png
Size: 127369 bytes
Desc: extent calculation.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/8ed9059b/attachment.png>

From kayla.skillin at boston.gov  Wed Mar  8 15:32:41 2017
From: kayla.skillin at boston.gov (Kayla Skillin)
Date: Wed, 8 Mar 2017 15:32:41 -0500
Subject: [Archivesspace_Users_Group] Report to count number of container
 types in a collection
In-Reply-To: <CY1PR08MB13113260628F588349EC4FF6E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
References: <CALSLJ1TDi7EcQySwkDfurF0Oo+iLpS1UY768Ran_w-C0YZPNig@mail.gmail.com>
 <CY1PR08MB13113260628F588349EC4FF6E42E0@CY1PR08MB1311.namprd08.prod.outlook.com>
Message-ID: <CALSLJ1QfmDwgk57w3RT378za-900smfu8uFrK5=uYTT4m1zttg@mail.gmail.com>

Thank you both; both of these options work for what I need!

- Kayla


[image: Digital_City_Seal_black.png]

Kayla Skillin

Assistant Archivist

City of Boston Archives

617.635.1195 (w)


On Wed, Mar 8, 2017 at 3:27 PM, Caldera, Mary <mary.caldera at yale.edu> wrote:

> Hi, Kayla,
>
>
>
> From the application, the easiest way might be to use the extent
> calculator at the resource level. The container types and numbers will be
> generated. Click Close instead of Create extent if you do not want to save
> the generated extant statement. Another way would be to use the Mange
> Containers functionality. It will list all the containers give you an count
> of all the containers, but not by type.
>
>
>
> I attach a png showing the extent calculated window.
>
> _______________________________
>
> ________________________________
>
>
>
> Mary Caldera,
>
> Head of Arrangement and Description
>
> Manuscripts and Archives
>
> Yale University Library
>
> P.O. Box 208240
>
> New Haven, CT  06520-8240
>
> 203/432-8019 <(203)%20432-8019>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Kayla
> Skillin
> *Sent:* Wednesday, March 8, 2017 2:08 PM
> *To:* archivesspace_users_group at lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] Report to count number of
> container types in a collection
>
>
>
> Hello,
>
>
>
> At the City of Boston Archives, we recently accessioned a large record
> group that contains mostly volumes. To make sure that we have an accurate
> inventory of every single volume, we were wondering if there was a report
> that we could run in ArchivesSpace that allows us to count these volumes?
> We are putting each volume in as an item and listing it as a volume in the
> top container instance so the data should be there, it's just a matter of
> extracting it.
>
>
>
> This might already exist and I just can't figure it out, but, does anyone
> have any insight into this?
>
>
>
> Thanks,
>
> Kayla
>
>
>
> [image: Digital_City_Seal_black.png]
>
> *Kayla Skillin*
>
> Assistant Archivist
>
> City of Boston Archives
>
> 617.635.1195 <(617)%20635-1195> (w)
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170308/6b60bbd6/attachment.html>

From s.innes at auckland.ac.nz  Thu Mar  9 00:18:51 2017
From: s.innes at auckland.ac.nz (Stephen Innes)
Date: Thu, 9 Mar 2017 05:18:51 +0000
Subject: [Archivesspace_Users_Group] References in Index notes
Message-ID: <19b221a2d7a34ce29c362f7af223a621@uxcn13-ogg-c.UoA.auckland.ac.nz>

We are having difficulty creating index entries linking from a list of terms at the top level of the finding aid to entries at the component level. We are using AS v1.4.2.

Can someone point us to the correct format for creating the references at the item level in an Index note? I am attaching a sample of current entries for some test index terms. The EAD for this section looks like this:

<index id="aspace_ac4fdf6cd76d3c793fb22a069e02f055">
    <head>Index of Drawings</head>
    <indexentry>
      <name>Avondale Masonic Hall.</name>
    </indexentry>
    <indexentry>
      <name>Bach extension at Langs Beach </name>
    </indexentry>
    <indexentry>
      <name>Block of eight flats.</name>
    </indexentry>
    <indexentry>
      <name>Cenotaph (Auckland?)</name>
    </indexentry>
    <indexentry>
      <name>Central service and parking station</name>
    </indexentry>
  </index>


Thanks,


Stephen Innes


Stephen Innes (ALIANZA)
Special Collections Manager
General Library, Te Herenga M?tauranga Wh?nui
The University of Auckland
Private Bag 92019
Auckland 1142
New Zealand
Telephone (649) 373-7599 ext. 88062 | Fax (649) 373-7565
Website: http://www.library.auckland.ac.nz/about-us/collections/special-collections/general-library
Online exhibition: Special Collections First World War Centenary 2014-2018<http://www.specialcollections.auckland.ac.nz/ww1-centenary>


From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kayla Skillin
Sent: Thursday, 9 March 2017 9:33 a.m.
To: Archivesspace Users Group
Subject: [FORGED] Re: [Archivesspace_Users_Group] Report to count number of container types in a collection

Thank you both; both of these options work for what I need!

- Kayla



[Digital_City_Seal_black.png]


Kayla Skillin

Assistant Archivist

City of Boston Archives

617.635.1195 (w)


On Wed, Mar 8, 2017 at 3:27 PM, Caldera, Mary <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>> wrote:
Hi, Kayla,

From the application, the easiest way might be to use the extent calculator at the resource level. The container types and numbers will be generated. Click Close instead of Create extent if you do not want to save the generated extant statement. Another way would be to use the Mange Containers functionality. It will list all the containers give you an count of all the containers, but not by type.

I attach a png showing the extent calculated window.
_______________________________
________________________________

Mary Caldera,
Head of Arrangement and Description
Manuscripts and Archives
Yale University Library
P.O. Box 208240
New Haven, CT  06520-8240
203/432-8019<tel:(203)%20432-8019>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Kayla Skillin
Sent: Wednesday, March 8, 2017 2:08 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Report to count number of container types in a collection

Hello,

At the City of Boston Archives, we recently accessioned a large record group that contains mostly volumes. To make sure that we have an accurate inventory of every single volume, we were wondering if there was a report that we could run in ArchivesSpace that allows us to count these volumes? We are putting each volume in as an item and listing it as a volume in the top container instance so the data should be there, it's just a matter of extracting it.

This might already exist and I just can't figure it out, but, does anyone have any insight into this?

Thanks,
Kayla


[Digital_City_Seal_black.png]


Kayla Skillin

Assistant Archivist

City of Boston Archives

617.635.1195<tel:(617)%20635-1195> (w)



_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/030d1a08/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 7077 bytes
Desc: image003.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/030d1a08/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: index-reference.png
Type: image/png
Size: 37508 bytes
Desc: index-reference.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/030d1a08/attachment-0001.png>

From christine.dibella at lyrasis.org  Thu Mar  9 11:03:59 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Thu, 9 Mar 2017 16:03:59 +0000
Subject: [Archivesspace_Users_Group] planning group for ArchivesSpace Member
 Forum at SAA 2017 - seeking volunteers from Very Small and Small and/or
 nonacademic members
Message-ID: <SN1PR08MB14062E1FE5CFD04DDA5C45E0F1210@SN1PR08MB1406.namprd08.prod.outlook.com>

Thanks so much to everyone who has volunteered for the Member Forum planning group so far - the response has been great and I look forward to convening the first meeting of the group very soon.

If you've been considering this, but have been on the fence about participating, please get in touch by Tuesday, March 14. While everyone is welcome, to ensure we have a wide variety of viewpoints represented, I'm particularly hoping to hear from at least one or two more volunteers from institutions in our Very Small or Small membership level, as well as at least one nonacademic institution. Past Member Forum planning group members can vouch that the time commitment is not very onerous, and that it's really satisfying to connect with others in the community and know what you're doing has such a positive impact. I'd be glad to talk with you more if you're interested but unsure about whether this is something you're able to fit into your schedule.

Christine

From: Christine Di Bella
Sent: Monday, March 6, 2017 9:07 AM
To: archivesspace_users_group at lyralists.lyrasis.org; 'Archivesspace Member Reps' <archivesspace_member_reps at lyralists.lyrasis.org>; 'archivesspace_tac_uac at lyralists.lyrasis.org' <archivesspace_tac_uac at lyralists.lyrasis.org>
Cc: 'archivesspace_bot_members at lyralists.lyrasis.org' <archivesspace_bot_members at lyralists.lyrasis.org>
Subject: call for planning group for ArchivesSpace Member Forum at SAA 2017

Hello ArchivesSpace members,

Plans are underway for this year's ArchivesSpace Members Forum, which will be held at Portland State University on July 25, 2017. This event will again be held in conjunction with the SAA conference, though we're hoping to also have an online component for those who can't attend in person. Like last year, we're looking to do a program that combines workshops, sessions, discussion groups, and program updates. It will be free and open to all staff of ArchivesSpace member institutions.

I'm looking for some ArchivesSpace members to assist me with developing the format and program, organizing face-to-face and online events, and, ideally, helping with logistics at the forum itself. If you're not planning to go to SAA this year, we could certainly still use help before and afterwards, but as you would imagine it's really useful to have as many people there to pitch in on the day of as we can. The overall time commitment will be less than 5 hours a month through July, plus any time spent at the forum itself.

Please drop me a line if you'd like to be involved and let me know whether or not you plan to attend SAA or otherwise be in Portland on July 25. I'm aiming to convene a first (phone) meeting of the planning group later this month.

If you need more information at this point, please just let me know. Thanks in advance!

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/be008db4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/be008db4/attachment.jpg>

From christine.dibella at lyrasis.org  Thu Mar  9 12:11:16 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Thu, 9 Mar 2017 17:11:16 +0000
Subject: [Archivesspace_Users_Group] specification for OAI-PMH responder
	available for comment
Message-ID: <SN1PR08MB1406DBA39D785561A20D0CCBF1210@SN1PR08MB1406.namprd08.prod.outlook.com>

Hello ArchivesSpace members,

Thanks to excellent work done by Cory Nimer and Gordon Daines of Brigham Young University and Jason Loeffler of the American Academy in Rome, a detailed software requirements specification for an Open Archives Initiative - Protocol for Metadata Harvesting (OAI-PMH) responder for ArchivesSpace is now available for comment. The specification is attached and also included in the JIRA issue https://archivesspace.atlassian.net/browse/AR-803.

The purpose of the responder would be to support a low-barrier mechanism for interoperability between archival metadata stored in ArchivesSpace and enterprise discovery layers (e.g., Ex Libris Primo), metadata aggregators (e.g., OAIster, Mountain West Digital Library), and content management systems (e.g. CONTENTdm, Drupal, Omeka). It would not replace any of the existing ways to get data out of ArchivesSpace, but would provide another option to facilitate data exchange between systems. More details about how this would work are included in the specification.

The best way to submit your feedback is to comment on the JIRA issue. (You can sign up for an account on our JIRA site, if you don't have one already.) Alternately, please email Cory (cory_nimer at byu.edu<mailto:cory_nimer at byu.edu>). The group would like to receive all comments by March 31.

Thanks again to Cory, Gordon, and Jason for taking this on, and thanks in advance to all those who provide feedback that will help us insure that this meets the identified need.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/c472a2a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/c472a2a3/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OAI-PMH responder SRS v.6.doc
Type: application/msword
Size: 134144 bytes
Desc: OAI-PMH responder SRS v.6.doc
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/c472a2a3/attachment.doc>

From jjones at smith.edu  Thu Mar  9 12:28:46 2017
From: jjones at smith.edu (Jasmine Jones)
Date: Thu, 9 Mar 2017 12:28:46 -0500
Subject: [Archivesspace_Users_Group] Smith College Special Collections RFP
 for data cleanup and ArchivesSpace migration
Message-ID: <CADExw5kM_h7Y5AU4hAmk4OYnscf0n+5sMfHonQC_mFsstQjaZw@mail.gmail.com>

Good afternoon, all:

Smith College Special Collections seeks a consultant to assist in the
cleanup and migration of its archival description and collections
management data to ArchivesSpace. We invite interested individuals to
submit a proposal, in accordance with the requirements sent forth in the
attached RFP.  The deadline for submitting a proposal and estimate is March
17, 2017.

If there are any questions about the RFP, please feel free to email me at
jjones at smith.edu. Thank you for your consideration and interest.

Best,

Jasmine Jones
Metadata and Technical Services Archivist

Smith College Special Collections
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/71881936/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmithCollege_RFPASpaceDataMigration.pdf
Type: application/pdf
Size: 438142 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170309/71881936/attachment-0001.pdf>

From calvin.miracle at louisville.edu  Fri Mar 10 05:17:33 2017
From: calvin.miracle at louisville.edu (calvin.miracle at louisville.edu)
Date: Fri, 10 Mar 2017 10:17:33 +0000
Subject: [Archivesspace_Users_Group] unsubscribe
Message-ID: <4FDFBF565F067745BAF6B38F5972A1D4014FE9240C@exmbx11>


________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [archivesspace_users_group-bounces at lyralists.lyrasis.org] on behalf of Jasmine Jones [jjones at smith.edu]
Sent: Thursday, March 09, 2017 12:28 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Smith College Special Collections RFP for data cleanup and ArchivesSpace migration

Good afternoon, all:

Smith College Special Collections seeks a consultant to assist in the cleanup and migration of its archival description and collections management data to ArchivesSpace. We invite interested individuals to submit a proposal, in accordance with the requirements sent forth in the attached RFP.  The deadline for submitting a proposal and estimate is March 17, 2017.

If there are any questions about the RFP, please feel free to email me at jjones at smith.edu<mailto:jjones at smith.edu>. Thank you for your consideration and interest.

Best,

Jasmine Jones
Metadata and Technical Services Archivist

Smith College Special Collections
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170310/4fc20245/attachment.html>

From jzarrillo at brooklynhistory.org  Mon Mar 13 12:29:00 2017
From: jzarrillo at brooklynhistory.org (John Zarrillo)
Date: Mon, 13 Mar 2017 16:29:00 +0000
Subject: [Archivesspace_Users_Group] Timing out exporting large EAD files
Message-ID: <CY1PR01MB2108B3C9F71FACBBB88AF2D3BB250@CY1PR01MB2108.prod.exchangelabs.com>

Has anyone else had issues exporting large EAD files from AS? We have a 4.3 MB EAD that times out whenever I try to export it. Any help is appreciated.

John Zarrillo
Senior Archivist
718-222-4111 x205
jzarrillo at brooklynhistory.org<mailto:jzarrillo at brooklynhistory.org>

[bhs-150-logo-horizontal-rgb.png]<http://www.brooklynhistory.org/>
Twitter<https://twitter.com/brooklynhistory> I Facebook<https://www.facebook.com/BrooklynHistory> I Instagram<http://instagram.com/brooklynhistory>

Quick Links: Visit the Library<http://brooklynhistory.org/library/visit.html> | Search the Collections<http://brooklynhistory.org/library/search.html> | Ask a Q<http://brooklynhistory.org/library/ask.html> | Class Visits<http://brooklynhistory.org/library/request.php> | Image Requests<http://brooklynhistory.org/docs/Collection_Reproduction_Application_Form_2014.pdf> | Donate<http://brooklynhistory.org/library/donation.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170313/601bb89b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21471 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170313/601bb89b/attachment.png>

From bthomas at tsl.texas.gov  Mon Mar 13 16:39:44 2017
From: bthomas at tsl.texas.gov (Brian Thomas)
Date: Mon, 13 Mar 2017 20:39:44 +0000
Subject: [Archivesspace_Users_Group] Problems linking containers to locations
Message-ID: <CY4PR1601MB13494539B3D0D4323206B09FFA250@CY4PR1601MB1349.namprd16.prod.outlook.com>

We seem to be having trouble with newer container functionality. When creating an instance within a resource we are able to successfully create a container but it won't let us link it to a container profile. We can search to find an existing container from the resource using things like searching for an unassociated container, but the type and search in the container name bar does not work. More importantly, we cannot link containers to locations. When I try to update the container with a location, rather than extending the page with additional options to find a location, it takes me from the edit option to just a normal view of the container. The linked resources aren't pulling up for containers either.

Any thoughts on what might be happening? This has happened with 1.5.1 (never resolved) and now 1.5.3. We are running the instance installed source and are using a Rhel type 5.11 server. We do not have ruby installed independent of the app.

Brian Thomas
Electronic Records Specialist
Texas State Library and Archives Commission
1201 Brazos Street
Austin, TX 78701
PH: (512) 475-3374
e-mail: bthomas at tsl.texas.gov
tsl.texas.gov<http://tsl.texas.gov/>
[cid:image001.jpg at 01D029A2.37194C70]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170313/0fa60b6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5314 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170313/0fa60b6c/attachment.png>

From hawkpf at miamioh.edu  Tue Mar 14 14:40:33 2017
From: hawkpf at miamioh.edu (Hawk, Patrick)
Date: Tue, 14 Mar 2017 14:40:33 -0400
Subject: [Archivesspace_Users_Group] Failure in periodic indexer worker
	thread
Message-ID: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having
issues getting my content to fully load.  I followed the instructions here:
http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.
I removed the directory /archivesspace/data/indexter_state and
/archivesspace/data/solr_index/index as the directions stated I should do
when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker
thread: {"error":"undefined method `related_records' for nil:NilClass"} in
the archivesspace.out file.  At this point the logs suggest that all items
have been re-indexed but my content does not fully load.  Any suggestions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/7542fb2b/attachment.html>

From sdm7g at eservices.virginia.edu  Tue Mar 14 15:13:17 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Tue, 14 Mar 2017 19:13:17 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic indexer
	worker	thread
In-Reply-To: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
Message-ID: <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>


Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here: http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/6df5d918/attachment.html>

From hawkpf at miamioh.edu  Tue Mar 14 15:27:08 2017
From: hawkpf at miamioh.edu (Hawk, Patrick)
Date: Tue, 14 Mar 2017 15:27:08 -0400
Subject: [Archivesspace_Users_Group] Failure in periodic indexer worker
	thread
In-Reply-To: <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
Message-ID: <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>

Steve,
The url you linked would be the same issue, so yes the indexer tries to
index the same items over and over...  I'll have to inspect the records to
see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu> wrote:

>
> Check for errors in the container conversion batch job log files.
>
> Does the indexer appear to keep trying to reindex the same records over
> and over ?
>
> See previous thread:
> http://lyralists.lyrasis.org/pipermail/archivesspace_users_
> group/2017-January/004370.html
>
> ? Steve Majewski
>
>
>
> On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu> wrote:
>
> Hello,
>
> I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having
> issues getting my content to fully load.  I followed the instructions here:
> http://archivesspace.github.io/archivesspace/user/
> upgrading-to-a-new-release-of-archivesspace/.  I removed the directory
> /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index
> as the directions stated I should do when upgrading to 1.5.0.  I also ran
> the setup-database.sh without issue.
>
> However, I receive the following error:  Failure in periodic indexer
> worker thread: {"error":"undefined method `related_records' for
> nil:NilClass"} in the archivesspace.out file.  At this point the logs
> suggest that all items have been re-indexed but my content does not fully
> load.  Any suggestions?
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 

Patrick Hawk


King Library Systems

King Library Room  314

513-529-6122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/55a414a6/attachment.html>

From jhamblet at nmu.edu  Tue Mar 14 15:40:08 2017
From: jhamblet at nmu.edu (Hambleton, John S)
Date: Tue, 14 Mar 2017 19:40:08 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic indexer
	worker	thread
In-Reply-To: <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
Message-ID: <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>

Hello!

That thread below was us, Northern Michigan University.
Looking in the container conversion log, was this error:

Error:
JSONModel::ValidationException

Message:
indicator_1 -- Mismatch when mapping between indicator and indicator_1

James Bullen took a look at our log and determined that there was a barcode
uniqueness problem between two accessions. So we cleaned that up and sure enough,
that was it. We re-ran the conversion and the indexer did not have any problems.

Hope this helps you.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hawk, Patrick
Sent: Tuesday, March 14, 2017 3:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

Steve,
The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here: http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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


_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/eab32613/attachment.html>

From Madeline.Sheldon at lyrasis.org  Tue Mar 14 17:01:15 2017
From: Madeline.Sheldon at lyrasis.org (Madeline Sheldon)
Date: Tue, 14 Mar 2017 21:01:15 +0000
Subject: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace
Message-ID: <SN1PR08MB140844FF071B16854A0E3BEA9B240@SN1PR08MB1408.namprd08.prod.outlook.com>

Hello,
Does anyone have experience migrating large amounts of table data from their finding aids into ArchivesSpace, and would be willing to share feedback? For example, did you end up adding the content into a "Notes" field? Just curious as to what strategies institutions employed and what final results looked like.

Thank you,
Madeline

---
Madeline Sheldon, MSI
Member Representative, Digital Technology Services<https://www.lyrasis.org/about/Pages/Meet-the-Member-Outreach-Team.aspx>
madeline.sheldon at lyrasis.org<mailto:madeline.sheldon at lyrasis.org>
Direct line: (404) 695-2229
Toll free: 800.999.8558 x2930 (rings to direct line)
Skype: msheldon.lyrasis

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Save the Date for the 2017 Member Summit: October 11-12

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/026c8165/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4072 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170314/026c8165/attachment.png>

From kkthompson at tsl.texas.gov  Wed Mar 15 13:37:36 2017
From: kkthompson at tsl.texas.gov (Kathleen Krause-Thompson)
Date: Wed, 15 Mar 2017 17:37:36 +0000
Subject: [Archivesspace_Users_Group] applying config.rb settings with Apache
	reverse proxy
Message-ID: <DM5PR16MB1386A3866386CC9C04F0328888270@DM5PR16MB1386.namprd16.prod.outlook.com>


I've configured an Apache reverse proxy for the frontend URL using the following instructions:

https://github.com/archivesspace/archivesspace/blob/master/README_HTTPS.md

Exception being that we chose to use a subdirectory instead of a prefix, as follows:

<VirtualHost *:443>
         ProxyPreserveHost On
         ProxyPass /staff http://aris.texas.gov:8080<http://aris.tsl.texas.gov:8080>
         ProxyPassReverse /staff http://aris.texas.gov:8080<http://aris.tsl.texas.gov:8080>

Then in the config.rb file I changed the AppConfig[:frontend_proxy_url] setting to:

         AppConfig[:frontend_proxy_url] = "https://aris.texas.gov/staff<https://aris.tsl.texas.gov/staff>"

With the configuration above, ASpace starts with no error messages, but there is a disconnect that causes problems with record editing processes. The URL, https://aris.texas.gov/staff/top_containers/8/edit, seems to not be able to carry out certain editing and browsing procedures.

I tried adding this setting to config.rb, AppConfig[:front_end]="https://aris.texas.gov/staff<https://aris.tsl.texas.gov/staff>", but that causes Jetty to fail when I restart ArchivesSpace.

Are there settings to use in config.rb or elsewhere that will fix the issue in red?

Thanks for taking a look.


Kathleen Krause-Thompson
Texas State Library and Archives
Lead Developer Analyst
512-463-5485

[tslac_logo_small]<https://www.tsl.texas.gov/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/b3c1f288/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 70 bytes
Desc: image001.gif
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/b3c1f288/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5344 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/b3c1f288/attachment.png>

From kate_bowers at harvard.edu  Wed Mar 15 14:03:26 2017
From: kate_bowers at harvard.edu (Bowers, Kate A.)
Date: Wed, 15 Mar 2017 18:03:26 +0000
Subject: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace
In-Reply-To: <SN1PR08MB140844FF071B16854A0E3BEA9B240@SN1PR08MB1408.namprd08.prod.outlook.com>
References: <SN1PR08MB140844FF071B16854A0E3BEA9B240@SN1PR08MB1408.namprd08.prod.outlook.com>
Message-ID: <CO1PR07MB3314E08F2D8E977F8BA7FC280270@CO1PR07MB331.namprd07.prod.outlook.com>

What do you mean by table data? Do you literally mean data in EAD <table>?


If so, I'd suggest reworking the EAD to put the data in semantic rather than in format tags.  Perhaps you can post an example?


Kate

Kate Bowers
Collections Services Archivist for Metadata, Systems, and Standards
Harvard University Archives
kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>
617.496.2713
voice: (617) 998-5238
fax: (617) 495-8011
web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
Twitter: @k8_bowers





________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Madeline Sheldon <Madeline.Sheldon at lyrasis.org>
Sent: Tuesday, March 14, 2017 5:01 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace


Hello,

Does anyone have experience migrating large amounts of table data from their finding aids into ArchivesSpace, and would be willing to share feedback? For example, did you end up adding the content into a ?Notes? field? Just curious as to what strategies institutions employed and what final results looked like.



Thank you,

Madeline



---

Madeline Sheldon, MSI

Member Representative, Digital Technology Services<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.lyrasis.org_about_Pages_Meet-2Dthe-2DMember-2DOutreach-2DTeam.aspx&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=ns_Li-tQ4Vuq5WGcw5RIcM66uUREivzqhE4wfdJ7mXk&s=X2B5lcNHh6UjgxCdpOfCjnT4UtoWxfF8dN_sjqeuvSY&e=>
madeline.sheldon at lyrasis.org<mailto:madeline.sheldon at lyrasis.org>

Direct line: (404) 695-2229

Toll free: 800.999.8558 x2930 (rings to direct line)

Skype: msheldon.lyrasis



[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]

Save the Date for the 2017 Member Summit: October 11-12


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/92c50b37/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4072 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/92c50b37/attachment.png>

From sdm7g at eservices.virginia.edu  Wed Mar 15 15:29:23 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 15 Mar 2017 19:29:23 +0000
Subject: [Archivesspace_Users_Group] applying config.rb settings with
 Apache	reverse proxy
In-Reply-To: <DM5PR16MB1386A3866386CC9C04F0328888270@DM5PR16MB1386.namprd16.prod.outlook.com>
References: <DM5PR16MB1386A3866386CC9C04F0328888270@DM5PR16MB1386.namprd16.prod.outlook.com>
Message-ID: <3ED733FC-59A5-4AB3-9E8D-AA521A5106CA@eservices.virginia.edu>



Although there are instructions for running ArchivesSpace with a prefix, I don?t believe it?s fully supported or tested. I did try to configure this at one time, but abandoned it after running into problems with the asset pipeline URLs. If you do want to see this feature working, please vote on it in Jira: it?s been a low priority in the past.

https://archivesspace.atlassian.net/browse/AR-1566


I just gave this a try on a test server, and it actually seems to work somewhat better that the last time I tried it. If you open the javascript console on your browser and you browse, you will see a bunch of 404 errors for hostname/assets/? ( i.e. /staff is not getting prefixed onto all of the javascript and css assets as it does for other URLs. )

Also: some redirects to the home page also omit the /staff prefix and send you back to the server root.
Some of those redirects appear to log me out as well, so when I go back to home I have to sign in again.

Despite the missing assets, most of the functionality appears to work for me, including editing top containers. Browsing top_containers after a search, however, doesn?t show any styling. It also doesn?t show any 404?s ? it doesn?t appear to be trying to load any other resources. However, the view and edit buttons work for me.  Since top_containers are a new addition, it?s not surprising that it hasn?t been tested with that prefix option.

Most of the missing assets appear to be images which wouldn?t greatly affect the functionality of the page.
However, I did think I saw some 404?s for javascript files while browsing around, although I can?t find the source of it again to reproduce it. I expected more breakage than I?m seeing now.

You can probably kludge the staff interface into working by adding redirects for /assets to /staff/assets.
I tried this initially, but if you also want to run the public interface with a different prefix, the problem is that you will also have /assets that should be redirected to /public/assets, and no way to disambiguate the two.



? Steve Majewski



On Mar 15, 2017, at 1:37 PM, Kathleen Krause-Thompson <kkthompson at tsl.texas.gov<mailto:kkthompson at tsl.texas.gov>> wrote:

<image001.gif>
I've configured an Apache reverse proxy for the frontend URL using the following instructions:

https://github.com/archivesspace/archivesspace/blob/master/README_HTTPS.md

Exception being that we chose to use a subdirectory instead of a prefix, as follows:

<VirtualHost *:443>
         ProxyPreserveHost On
         ProxyPass /staff http://aris.texas.gov:8080<http://aris.tsl.texas.gov:8080/>
         ProxyPassReverse /staff http://aris.texas.gov:8080<http://aris.tsl.texas.gov:8080/>

Then in the config.rb file I changed the AppConfig[:frontend_proxy_url] setting to:

         AppConfig[:frontend_proxy_url] = "https://aris.texas.gov/staff<https://aris.tsl.texas.gov/staff>"

With the configuration above, ASpace starts with no error messages, but there is a disconnect that causes problems with record editing processes. The URL, https://aris.texas.gov/staff/top_containers/8/edit, seems to not be able to carry out certain editing and browsing procedures.

I tried adding this setting to config.rb, AppConfig[:front_end]="https://aris.texas.gov/staff<https://aris.tsl.texas.gov/staff>", but that causes Jetty to fail when I restart ArchivesSpace.




I assume you meant AppConfig[:frontend_url] above. I don?t think you want to change that. Only the :frontend_proxy_url .


Are there settings to use in config.rb or elsewhere that will fix the issue in red?

Thanks for taking a look.


Kathleen Krause-Thompson
Texas State Library and Archives
Lead Developer Analyst
512-463-5485

<image002.png><https://www.tsl.texas.gov/>

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170315/9b5863b9/attachment.html>

From hawkpf at miamioh.edu  Thu Mar 16 12:10:26 2017
From: hawkpf at miamioh.edu (Hawk, Patrick)
Date: Thu, 16 Mar 2017 12:10:26 -0400
Subject: [Archivesspace_Users_Group] Failure in periodic indexer worker
	thread
In-Reply-To: <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
Message-ID: <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>

John,
Do you know which two accessions you had to modify?

Also, this is what I see in archivesspace/logs/archivesspace.out

<:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping
between indicator and indicator_1"]},
:object_context=>{:top_container=>#<TopContainer @values={:id=>2,
:repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami
University Archives (Western College for Women Collection)",
:ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil,
:indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX",
:create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48
UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>,
:aspace_container=>{"lock_version"=>0, "indicator_1"=>"2",
"barcode_1"=>"Miami University Archives (Western College for Women
Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX",
"last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z",
"system_mtime"=>"2016-11-15T18:16:09Z",
"user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box",
"container_extent_type"=>"Boxes", "jsonmodel_type"=>"container",
"container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31",
"system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01
UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>



On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu> wrote:

> Hello!
>
>
>
> That thread below was us, Northern Michigan University.
>
> Looking in the container conversion log, was this error:
>
>
>
> Error:
>
> JSONModel::ValidationException
>
>
>
> Message:
>
> indicator_1 -- Mismatch when mapping between indicator and indicator_1
>
>
>
> James Bullen took a look at our log and determined that there was a barcode
>
> uniqueness problem between two accessions. So we cleaned that up and sure
> enough,
>
> that was it. We re-ran the conversion and the indexer did not have any
> problems.
>
>
>
> Hope this helps you.
>
>
>
> John H
>
> NMU
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Hawk,
> Patrick
> *Sent:* Tuesday, March 14, 2017 3:27 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Failure in periodic indexer
> worker thread
>
>
>
> Steve,
> The url you linked would be the same issue, so yes the indexer tries to
> index the same items over and over...  I'll have to inspect the records to
> see what is causing the migration to fail.
>
>
>
> On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <
> sdm7g at eservices.virginia.edu> wrote:
>
>
>
> Check for errors in the container conversion batch job log files.
>
>
>
> Does the indexer appear to keep trying to reindex the same records over
> and over ?
>
>
>
> See previous thread:
>
> http://lyralists.lyrasis.org/pipermail/archivesspace_users_
> group/2017-January/004370.html
>
>
>
> ? Steve Majewski
>
>
>
>
>
>
>
> On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu> wrote:
>
>
>
> Hello,
>
> I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having
> issues getting my content to fully load.  I followed the instructions here:
> http://archivesspace.github.io/archivesspace/user/
> upgrading-to-a-new-release-of-archivesspace/.  I removed the directory
> /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index
> as the directions stated I should do when upgrading to 1.5.0.  I also ran
> the setup-database.sh without issue.
>
>
>
> However, I receive the following error:  Failure in periodic indexer
> worker thread: {"error":"undefined method `related_records' for
> nil:NilClass"} in the archivesspace.out file.  At this point the logs
> suggest that all items have been re-indexed but my content does not fully
> load.  Any suggestions?
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
>
> --
>
> Patrick Hawk
>
> King Library Systems
>
> King Library Room  314
>
> 513-529-6122 <(513)%20529-6122>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 

Patrick Hawk


King Library Systems

King Library Room  314

513-529-6122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170316/559ead38/attachment.html>

From jhamblet at nmu.edu  Thu Mar 16 12:47:36 2017
From: jhamblet at nmu.edu (Hambleton, John S)
Date: Thu, 16 Mar 2017 16:47:36 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic indexer
	worker	thread
In-Reply-To: <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
Message-ID: <fc7a5ec281a141bab1698fd47432a4d8@EX01.ads.nmu.edu>

I replied off list to you Patrick, best I could, showing which Accessions WE had to modify,
basically we had to make ?barcode? unique between two accessions which, put us on the road.
But I?m not an expert in deciphering these errors. If my reply was not helpful perhaps one of
the ArchivesSpace support can better assist.

Best,
John H

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hawk, Patrick
Sent: Thursday, March 16, 2017 12:10 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

John,
Do you know which two accessions you had to modify?

Also, this is what I see in archivesspace/logs/archivesspace.out

<:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami University Archives (Western College for Women Collection)", :ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0, "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western College for Women Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX", "last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z", "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box", "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container", "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31", "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01 UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>


On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu>> wrote:
Hello!

That thread below was us, Northern Michigan University.
Looking in the container conversion log, was this error:

Error:
JSONModel::ValidationException

Message:
indicator_1 -- Mismatch when mapping between indicator and indicator_1

James Bullen took a look at our log and determined that there was a barcode
uniqueness problem between two accessions. So we cleaned that up and sure enough,
that was it. We re-ran the conversion and the indexer did not have any problems.

Hope this helps you.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Hawk, Patrick
Sent: Tuesday, March 14, 2017 3:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

Steve,
The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here: http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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


_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170316/a244d70e/attachment.html>

From sdm7g at eservices.virginia.edu  Thu Mar 16 13:10:11 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Thu, 16 Mar 2017 17:10:11 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic indexer
	worker	thread
In-Reply-To: <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
Message-ID: <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>


I interpret that error message as saying that you are trying to assign the same barcode ( "Miami University Archives (Western College for Women Collection)? ) to ?box 1? and ?box 2? (type + indicator). Barcodes must be unique. A collection name is not likely to be unique if there are more than one containers. Typically, these are machine scannable barcode numbers.  If you really want to use the collection name here, you could maybe append the box numbers to the ends of both, making them unique.


? Steve.


On Mar 16, 2017, at 12:10 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

John,
Do you know which two accessions you had to modify?

Also, this is what I see in archivesspace/logs/archivesspace.out

<:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami University Archives (Western College for Women Collection)", :ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0, "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western College for Women Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX", "last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z", "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box", "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container", "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31", "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01 UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>



On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu>> wrote:
Hello!

That thread below was us, Northern Michigan University.
Looking in the container conversion log, was this error:

Error:
JSONModel::ValidationException

Message:
indicator_1 -- Mismatch when mapping between indicator and indicator_1

James Bullen took a look at our log and determined that there was a barcode
uniqueness problem between two accessions. So we cleaned that up and sure enough,
that was it. We re-ran the conversion and the indexer did not have any problems.

Hope this helps you.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Hawk, Patrick
Sent: Tuesday, March 14, 2017 3:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

Steve,
The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here: http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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


_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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




--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170316/14b72cfb/attachment.html>

From Madeline.Sheldon at lyrasis.org  Fri Mar 17 09:14:28 2017
From: Madeline.Sheldon at lyrasis.org (Madeline Sheldon)
Date: Fri, 17 Mar 2017 13:14:28 +0000
Subject: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace
In-Reply-To: <CO1PR07MB3314E08F2D8E977F8BA7FC280270@CO1PR07MB331.namprd07.prod.outlook.com>
References: <SN1PR08MB140844FF071B16854A0E3BEA9B240@SN1PR08MB1408.namprd08.prod.outlook.com>
 <CO1PR07MB3314E08F2D8E977F8BA7FC280270@CO1PR07MB331.namprd07.prod.outlook.com>
Message-ID: <SN1PR08MB14083AABFD6158A4AE6D08829B390@SN1PR08MB1408.namprd08.prod.outlook.com>

Hi Kate,
Thank you for getting back to me. I don't have any examples to share, as I was mostly asking for my benefit and education. I think what you shared makes sense.

Madeline

---
Madeline Sheldon, MSI
Member Representative, Digital Technology Services<https://www.lyrasis.org/about/Pages/Meet-the-Member-Outreach-Team.aspx>
madeline.sheldon at lyrasis.org<mailto:madeline.sheldon at lyrasis.org>
Direct line: (404) 695-2229
Toll free: 800.999.8558 x2930 (rings to direct line)
Skype: msheldon.lyrasis

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Save the Date for the 2017 Member Summit: October 11-12

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A.
Sent: Wednesday, March 15, 2017 2:03 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: Re: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace


What do you mean by table data? Do you literally mean data in EAD <table>?



If so, I'd suggest reworking the EAD to put the data in semantic rather than in format tags.  Perhaps you can post an example?



Kate


Kate Bowers
Collections Services Archivist for Metadata, Systems, and Standards
Harvard University Archives
kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>
617.496.2713
voice: (617) 998-5238
fax: (617) 495-8011
web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
Twitter: @k8_bowers



________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Madeline Sheldon <Madeline.Sheldon at lyrasis.org<mailto:Madeline.Sheldon at lyrasis.org>>
Sent: Tuesday, March 14, 2017 5:01 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Migrating tables into ArchivesSpace


Hello,

Does anyone have experience migrating large amounts of table data from their finding aids into ArchivesSpace, and would be willing to share feedback? For example, did you end up adding the content into a "Notes" field? Just curious as to what strategies institutions employed and what final results looked like.



Thank you,

Madeline



---

Madeline Sheldon, MSI

Member Representative, Digital Technology Services<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.lyrasis.org_about_Pages_Meet-2Dthe-2DMember-2DOutreach-2DTeam.aspx&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=ns_Li-tQ4Vuq5WGcw5RIcM66uUREivzqhE4wfdJ7mXk&s=X2B5lcNHh6UjgxCdpOfCjnT4UtoWxfF8dN_sjqeuvSY&e=>
madeline.sheldon at lyrasis.org<mailto:madeline.sheldon at lyrasis.org>

Direct line: (404) 695-2229

Toll free: 800.999.8558 x2930 (rings to direct line)

Skype: msheldon.lyrasis



[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]

Save the Date for the 2017 Member Summit: October 11-12


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/5a91494a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4072 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/5a91494a/attachment.png>

From christine.dibella at lyrasis.org  Fri Mar 17 11:52:39 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Fri, 17 Mar 2017 15:52:39 +0000
Subject: [Archivesspace_Users_Group] announcing ArchivesSpace v1.5.4 - patch
 release to fix METS export only
Message-ID: <SN1PR08MB140632FBA05F81C34CD241B7F1390@SN1PR08MB1406.namprd08.prod.outlook.com>

The ArchivesSpace program team is announcing the availability of a small patch release, 1.5.4. This release remedies an issue that was preventing the METS export for digital objects from running. While our big focus right  now is on the next major release of ArchivesSpace (2.0.0), we're releasing 1.5.4 now in the interest of minimizing disruption for those that use the METS export.

As this is the only difference from 1.5.3 and this fix will also be in 2.0.0, current ArchivesSpace users only need to upgrade to this release if they use or plan to use the METS export. New ArchivesSpace users or those who have not yet upgraded to 1.5.3 should start from or upgrade directly to 1.5.4 when ready.

You can download this release at https://github.com/archivesspace/archivesspace/releases/tag/v1.5.4. Information on upgrading to a new version of ArchivesSpace is available at http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.

We apologize for the inconvenience but were glad to be able to quickly identify and remedy the issue. If you have any questions or need assistance, please don't hesitate to be in touch.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/c6e7ec67/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/c6e7ec67/attachment.jpg>

From christine.dibella at lyrasis.org  Fri Mar 17 15:06:06 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Fri, 17 Mar 2017 19:06:06 +0000
Subject: [Archivesspace_Users_Group] position opening: ArchivesSpace
	Community Engagement Coordinator
Message-ID: <SN1PR08MB140658D445C6F4127B512FDCF1390@SN1PR08MB1406.namprd08.prod.outlook.com>

Hello ArchivesSpace members,

I wanted to call your attention to this newly titled opening on the ArchivesSpace team. The Community Engagement Coordinator will be on the frontlines of the program, helping ArchivesSpace users get as much as possible out of the application and bringing our community together. S/he will work closely with Laney, me, and the ArchivesSpace community overall in areas including user support, outreach, communications, training, user documentation, and testing. (Having been in this role before, I can personally attest to what a great opportunity it is to get to involved in all facets of ArchivesSpace and the archives community!)

The full listing is attached and also available on the LYRASIS website at https://www.lyrasis.org/job/Pages/LYRASIS-Positions.aspx. We'll be posting it more widely beginning next week, but feel free to forward it to people you think might be interested at any point. Those interested in the position should apply by submitting a cover letter and resume to human.resources at lyrasis.org<mailto:human.resources at lyrasis.org>. Priority consideration will be given to applications received by April 21. If you have any questions about the position, or ideas on good candidates, please get in touch - we look forward to completing the ArchivesSpace team very soon.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/b654dd48/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image003.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/b654dd48/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ASpaceComm-Eng-Coord.pdf
Type: application/pdf
Size: 101629 bytes
Desc: ASpaceComm-Eng-Coord.pdf
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170317/b654dd48/attachment.pdf>

From brent_ellingson at byu.edu  Wed Mar 22 18:00:15 2017
From: brent_ellingson at byu.edu (Brent Ellingson)
Date: Wed, 22 Mar 2017 22:00:15 +0000
Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
Message-ID: <c79e089e2fd74c369c9aaa00b7a3f35e@MB7.byu.local>

We are in the process of upgrading our site from 1.4.2 to 1.5.3 and we are seeing a similar error as has been described in this thread. We are seeing the error below and continued looping of the indexer trying to index the archival objects.



~~~ Indexed 1225 of 67886 archival_object records in repository 2 ( added 25 records in  6399.0ms ) ~~~

~~~ Indexed 1250 of 67886 archival_object records in repository 2 ( added 25 records in  5488.0ms ) ~~~

E, [2017-03-16T16:53:51.425000 #779] ERROR -- : Thread-2392462: Unhandled exception!

E, [2017-03-16T16:53:51.425000 #779] ERROR -- :

undefined method `related_records' for nil:NilClass

/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'

/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'

/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'

org/jruby/RubyHash.java:1341:in `each'

org/jruby/RubyEnumerable.java:757:in `map'



Does a resolution to this issue exist?

How do I find what the offending set of data is causing the problem?

How do I proceed?



Thank you for your help.



Regards,
__________________________
Brent Ellingson
Sr. Software Engineer
BYU Library
801-422-6148




Date: Mon, 23 Jan 2017 19:54:53 +0000

From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>

To: Archivesspace Users Group

                <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>

Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2

Message-ID:

                <1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu<mailto:1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu>>

Content-Type: text/plain; charset="utf-8"





The first two issues appear to be due to trailing spaces in some of the container barcodes.

Top containers have already been created for barcodes without trailing space, and so it appears that the barcodes don?t match.







On Jan 20, 2017, at 3:49 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:





On Jan 13, 2017, at 6:15 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com<mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:





Hi Steve,



That fits the pattern I?m seeing in John?s data. Have you checked the container conversion log for any errors relating to that record?





Cheers,

James







Just re-did migration from 1.4.2 to 1.5.1 again, and I?m inspecting the logs.



Yes, archival_objects/255 is on that list.



error,message,url

JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331>

JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059>

JSONModel::ValidationException,indicator_1 -- Mismatch when mapping between indicator and indicator_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255>







I need to inspect the other repo logs and see if all of the ones that break are getting caught, but it looks likely.



I?m trying to interpret what exactly those messages are complaining about.

Do those error messages and object dumps mean anything to you off the bat?



? Steve.





On Jan 14, 2017, at 8:37 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:





It looks like the indexer gives and error because the backend is getting an error turning the SQL model into a JSON model.



For some of the archival objects that are failing to index, the significant difference is that they do not have a sub_container in their instance. Trying to access the json from the backend in 1.5.2 just yields an error message, but going back to test 1.5.1 migration:



[ This is json from the same screen capture in my previous message. ]



archival_object 255 ( which causes error on index )



{

  "lock_version": 0,

  "position": 17,

  "publish": true,

  "ref_id": "aspace_22a35d6a6ee59ac454ca8f35232b0b40",

  "title": "Buttons and uniform parts, souvenirs, and medals",

  "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",

  "restrictions_apply": false,

  "created_by": "admin",

  "last_modified_by": "admin",

  "create_time": "2015-08-11T21:43:55Z",

  "system_mtime": "2017-01-06T22:25:38Z",

  "user_mtime": "2015-08-11T21:43:55Z",

  "suppressed": false,

  "level": "file",

  "jsonmodel_type": "archival_object",

  "external_ids": [],

  "subjects": [],

  "linked_events": [],

  "extents": [],

  "dates": [

    {

      "lock_version": 0,

      "expression": "undated",

      "created_by": "admin",

      "last_modified_by": "admin",

      "create_time": "2015-08-11T21:43:55Z",

      "system_mtime": "2015-08-11T21:43:55Z",

      "user_mtime": "2015-08-11T21:43:55Z",

      "date_type": "inclusive",

      "label": "creation",

      "jsonmodel_type": "date"

    }

  ],

  "external_documents": [],

  "rights_statements": [],

  "linked_agents": [],

  "instances": [

    {

      "lock_version": 0,

      "created_by": "admin",

      "last_modified_by": "admin",

      "create_time": "2015-08-11T21:43:55Z",

      "system_mtime": "2015-08-11T21:43:55Z",

      "user_mtime": "2015-08-11T21:43:55Z",

      "instance_type": "Realia",

      "jsonmodel_type": "instance",

      "is_representative": false,

      "container": {

        "lock_version": 0,

        "indicator_1": "Artifacts 1",

        "barcode_1": "X030898965",

        "created_by": "admin",

        "last_modified_by": "admin",

        "create_time": "2015-08-11T21:43:55Z",

        "system_mtime": "2016-11-22T16:58:54Z",

        "user_mtime": "2015-08-11T21:43:55Z",

        "type_1": "box",

        "jsonmodel_type": "container",

        "container_locations": []

      }

    }

  ],

  "notes": [],

  "uri": "/repositories/3/archival_objects/255",

  "repository": {

    "ref": "/repositories/3"

  },

  "resource": {

    "ref": "/repositories/3/resources/11"

  },

  "has_unpublished_ancestor": false

}



archival_object 256: ( indexes successfully, once 255 is deleted. )



{

  "lock_version": 0,

  "position": 18,

  "publish": false,

  "ref_id": "aspace_15da7f2a9b0184a65b1280ae05a7598a",

  "title": "Buttons and uniform parts, souvenirs, and medals",

  "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",

  "restrictions_apply": false,

  "created_by": "admin",

  "last_modified_by": "admin",

  "create_time": "2015-08-11T21:43:55Z",

  "system_mtime": "2017-01-06T22:25:38Z",

  "user_mtime": "2015-08-11T21:43:55Z",

  "suppressed": false,

  "level": "file",

  "jsonmodel_type": "archival_object",

  "external_ids": [],

  "subjects": [],

  "linked_events": [],

  "extents": [],

  "dates": [

    {

      "lock_version": 0,

      "expression": "undated",

      "created_by": "admin",

      "last_modified_by": "admin",

      "create_time": "2015-08-11T21:43:55Z",

      "system_mtime": "2015-08-11T21:43:55Z",

      "user_mtime": "2015-08-11T21:43:55Z",

      "date_type": "inclusive",

      "label": "creation",

      "jsonmodel_type": "date"

    }

  ],

  "external_documents": [],

  "rights_statements": [],

  "linked_agents": [],

  "instances": [

    {

      "lock_version": 0,

      "created_by": "admin",

      "last_modified_by": "admin",

      "create_time": "2015-08-11T21:43:55Z",

      "system_mtime": "2015-08-11T21:43:55Z",

      "user_mtime": "2015-08-11T21:43:55Z",

      "instance_type": "Realia",

      "jsonmodel_type": "instance",

      "is_representative": false,

      "sub_container": {

        "lock_version": 0,

        "created_by": "admin",

        "last_modified_by": "admin",

        "create_time": "2017-01-06T22:28:29Z",

        "system_mtime": "2017-01-06T22:28:29Z",

        "user_mtime": "2017-01-06T22:28:29Z",

        "jsonmodel_type": "sub_container",

        "top_container": {

          "ref": "/repositories/3/top_containers/1573"

        }

      },

      "container": {

        "type_1": "box",

        "indicator_1": "Artifacts 2",

        "barcode_1": "X030866782",

        "container_locations": [],

        "lock_version": 1

      }

    }

  ],

  "notes": [],

  "uri": "/repositories/3/archival_objects/256",

  "repository": {

    "ref": "/repositories/3"

  },

  "resource": {

    "ref": "/repositories/3/resources/11"

  },

  "has_unpublished_ancestor": false

}







But as I noted previously, I don?t see the significant difference in the data in 1.4.2 that was migrated that would account for one failing and the other succeeding.





( It appears that there are other records causing errors that don?t necessarily fit this same pattern. )



But the fact that this info is missing in the 1.5.1 migration does suggest it?s not a 1.5.2 only bug, but a problem with the container migration in earlier versions that is just made more visible by some 1.5.2 changes.





? Steve.







On Jan 12, 2017, at 11:39 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com<mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:





Hi,



It looks like the problem John is seeing with the indexer failing after upgrading to 1.5.2 is caused by an issue with a record following the container conversion. I?m following up with John off-list on the specifics of his problem. Hopefully we?ll be able to confirm this when we get to a resolution.



The container management upgrade has been the source of quite a few bugs and it is on our radar for review.





Cheers,

James







On Jan 13, 2017, at 1:30 AM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu<mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:



Yes, thank you,

I sent my data to you off-list.



John H

NMU



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org%3cmailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of James Bullen

Sent: Wednesday, January 11, 2017 6:56 PM

To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org%3cmailto:archivesspace_users_group at lyralists.lyrasis.org>>>

Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2





Hi John and Steve,



Can either of you send some sample data that surfaces this bug?





Cheers,

James





On Jan 12, 2017, at 8:17 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:





After seeing this message, I tried 1.5.2 on my Mac (10.11.6) laptop and I?m also seeing the same undefined method `related_records' for nil:NilClass error, whether or not I do an intervening ( and successful, BTW ) update to 1.5.1.

Reindexing never seems to progress and so browse resources never shows any records.





? Steve Majewski







On Jan 11, 2017, at 1:58 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu<mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:



Folks,



I am testing archivesspace 1.5.2 on CentOS 6, using a copy of our 1.4.2 production database.

Wondering why it seems like the indexer is taking so long to finish, I am seeing this in the archivesspace.out log, which makes me think the indexer is caught in an endless loop:



Keep seeing the SAME indexer messages over and over again:

~~~ Indexed 1475 of 1941 accession records in repository 3 ( added 25 records in  8229.0ms ) ~~~ ~~~ Indexed 1500 of 1941 accession records in repository 3 ( added 25 records in  5251.0ms ) ~~~



And then,



E, [2017-01-11T13:41:10.740000 #32733] ERROR -- : Thread-6445852: Unhandled exception!

E, [2017-01-11T13:41:10.741000 #32733] ERROR -- :

undefined method `related_records' for nil:NilClass /usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'

/usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'

/usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'

org/jruby/RubyHash.java:1341:in `each'



And then seems to start indexing the same data over again:

~~~ Indexed 50 of 1941 accession records in repository 3 ( added 25 records in  11153.0ms ) ~~~ ~~~ Indexed 75 of 1941 accession records in repository 3 ( added 25 records in  10051.0ms ) ~~~ ~~~ Indexed 100 of 1941 accession records in repository 3 ( added 25 records in  9558.0ms ) ~~~



Kind of looks like the indexer errors on ?something? then, tries to reindex the same accession records over and over again. I had followed the advice here:https://github.com/archivesspace/archivesspace/blob/master/UPGRADING_1.5.0.md#conversion

before starting archivesspace, that is, ?delete your Solr index files to start with a fresh index?.



Any help is appreciated.

Thanks,

John H

NMU



_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group







!DSPAM:587793334611909212977! _______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group





!DSPAM:587793334611909212977!



_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



!DSPAM:587948af109451970717657!

_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group





!DSPAM:587948af109451970717657!



_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



<7ebc58861f8c38997d24d1316e9276ec>_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170322/b95e68e7/attachment.html>

From sdm7g at eservices.virginia.edu  Wed Mar 22 20:00:46 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Thu, 23 Mar 2017 00:00:46 +0000
Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
In-Reply-To: <c79e089e2fd74c369c9aaa00b7a3f35e@MB7.byu.local>
References: <c79e089e2fd74c369c9aaa00b7a3f35e@MB7.byu.local>
Message-ID: <DFC2DE6F-573D-4405-BC59-5E87E9A18C64@eservices.virginia.edu>

I?m going by memory, as I didn?t keep a copy of the filesystem from one of the failed install attempts:

When you performed the upgrade, some container conversion background jobs were run automatically for each repository. If you find them by browsing background jobs and looking for container_conversion jobs. The files are also in archivesspace/data/shared/job_files/container_conversion_job_*/ on the server.

2 files:
  output.log is the progress log that also displays in the batch_jobs console window.
  The other is an opaque hex digit identifier named file on the server, but probably downloads from that background joh page as something like container_conversion_jobnnn.csv .

That second file, should only have 1 line containing comma separated column names if there were no errors on the container conversion job:

error,message,url,uri,parent,resource,instances,instance_ids,preconversion_locations,postconversion_locations,conversion_context


If there are more lines following, that will have the error message and the uri of the record causing the error.

You may, however, also get an error if you try to access that object via either frontend or the backend API. So you may need to inspect and fix the object in 1.4.2, and then repeat the migration.

( If you didn?t test this first on a backup copy, as advised, I don?t know if you can perform a down migration again: not something I?ve ever tried.  You may have to fix it in MySQL. )

As we noted in that thread, the two common problems are either barcodes that are expected to be the same because the refer to the same container, are different ( and leading or trailing whitespace counts as different ), or else two different top_containers appear to have the same barcode ( in our case, it was a typo: same barcode was mistakenly assigned to the following container. ) In the case of a duplicate, I don?t think it tells you the id of the first instance of the duplicate. It?s the 2nd time that causes the error. You you will have to get the barcode from the 2nd and search for the other(s).

I hope the above fills in enough of the missing context from the thread below to figure out the source of your problem!

? Steve.




On Mar 22, 2017, at 6:00 PM, Brent Ellingson <brent_ellingson at byu.edu<mailto:brent_ellingson at byu.edu>> wrote:

We are in the process of upgrading our site from 1.4.2 to 1.5.3 and we are seeing a similar error as has been described in this thread. We are seeing the error below and continued looping of the indexer trying to index the archival objects.

~~~ Indexed 1225 of 67886 archival_object records in repository 2 ( added 25 records in  6399.0ms ) ~~~
~~~ Indexed 1250 of 67886 archival_object records in repository 2 ( added 25 records in  5488.0ms ) ~~~
E, [2017-03-16T16:53:51.425000 #779] ERROR -- : Thread-2392462: Unhandled exception!
E, [2017-03-16T16:53:51.425000 #779] ERROR -- :
undefined method `related_records' for nil:NilClass
/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'
/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'
/opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'
org/jruby/RubyHash.java:1341:in `each'
org/jruby/RubyEnumerable.java:757:in `map'

Does a resolution to this issue exist?
How do I find what the offending set of data is causing the problem?
How do I proceed?

Thank you for your help.

Regards,
__________________________
Brent Ellingson
Sr. Software Engineer
BYU Library
801-422-6148


Date: Mon, 23 Jan 2017 19:54:53 +0000
From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
To: Archivesspace Users Group
                <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
Message-ID:
                <1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu<mailto:1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu>>
Content-Type: text/plain; charset="utf-8"


The first two issues appear to be due to trailing spaces in some of the container barcodes.
Top containers have already been created for barcodes without trailing space, and so it appears that the barcodes don?t match.



On Jan 20, 2017, at 3:49 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:


On Jan 13, 2017, at 6:15 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com<mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:


Hi Steve,

That fits the pattern I?m seeing in John?s data. Have you checked the container conversion log for any errors relating to that record?


Cheers,
James



Just re-did migration from 1.4.2 to 1.5.1 again, and I?m inspecting the logs.

Yes, archival_objects/255 is on that list.

error,message,url
JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331><http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331>
JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059><http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059>
JSONModel::ValidationException,indicator_1 -- Mismatch when mapping between indicator and indicator_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255><http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255>



I need to inspect the other repo logs and see if all of the ones that break are getting caught, but it looks likely.

I?m trying to interpret what exactly those messages are complaining about.
Do those error messages and object dumps mean anything to you off the bat?

? Steve.


On Jan 14, 2017, at 8:37 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:


It looks like the indexer gives and error because the backend is getting an error turning the SQL model into a JSON model.

For some of the archival objects that are failing to index, the significant difference is that they do not have a sub_container in their instance. Trying to access the json from the backend in 1.5.2 just yields an error message, but going back to test 1.5.1 migration:

[ This is json from the same screen capture in my previous message. ]

archival_object 255 ( which causes error on index )

{
  "lock_version": 0,
  "position": 17,
  "publish": true,
  "ref_id": "aspace_22a35d6a6ee59ac454ca8f35232b0b40",
  "title": "Buttons and uniform parts, souvenirs, and medals",
  "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",
  "restrictions_apply": false,
  "created_by": "admin",
  "last_modified_by": "admin",
  "create_time": "2015-08-11T21:43:55Z",
  "system_mtime": "2017-01-06T22:25:38Z",
  "user_mtime": "2015-08-11T21:43:55Z",
  "suppressed": false,
  "level": "file",
  "jsonmodel_type": "archival_object",
  "external_ids": [],
  "subjects": [],
  "linked_events": [],
  "extents": [],
  "dates": [
    {
      "lock_version": 0,
      "expression": "undated",
      "created_by": "admin",
      "last_modified_by": "admin",
      "create_time": "2015-08-11T21:43:55Z",
      "system_mtime": "2015-08-11T21:43:55Z",
      "user_mtime": "2015-08-11T21:43:55Z",
      "date_type": "inclusive",
      "label": "creation",
      "jsonmodel_type": "date"
    }
  ],
  "external_documents": [],
  "rights_statements": [],
  "linked_agents": [],
  "instances": [
    {
      "lock_version": 0,
      "created_by": "admin",
      "last_modified_by": "admin",
      "create_time": "2015-08-11T21:43:55Z",
      "system_mtime": "2015-08-11T21:43:55Z",
      "user_mtime": "2015-08-11T21:43:55Z",
      "instance_type": "Realia",
      "jsonmodel_type": "instance",
      "is_representative": false,
      "container": {
        "lock_version": 0,
        "indicator_1": "Artifacts 1",
        "barcode_1": "X030898965",
        "created_by": "admin",
        "last_modified_by": "admin",
        "create_time": "2015-08-11T21:43:55Z",
        "system_mtime": "2016-11-22T16:58:54Z",
        "user_mtime": "2015-08-11T21:43:55Z",
        "type_1": "box",
        "jsonmodel_type": "container",
        "container_locations": []
      }
    }
  ],
  "notes": [],
  "uri": "/repositories/3/archival_objects/255",
  "repository": {
    "ref": "/repositories/3"
  },
  "resource": {
    "ref": "/repositories/3/resources/11"
  },
  "has_unpublished_ancestor": false
}

archival_object 256: ( indexes successfully, once 255 is deleted. )

{
  "lock_version": 0,
  "position": 18,
  "publish": false,
  "ref_id": "aspace_15da7f2a9b0184a65b1280ae05a7598a",
  "title": "Buttons and uniform parts, souvenirs, and medals",
  "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",
  "restrictions_apply": false,
  "created_by": "admin",
  "last_modified_by": "admin",
  "create_time": "2015-08-11T21:43:55Z",
  "system_mtime": "2017-01-06T22:25:38Z",
  "user_mtime": "2015-08-11T21:43:55Z",
  "suppressed": false,
  "level": "file",
  "jsonmodel_type": "archival_object",
  "external_ids": [],
  "subjects": [],
  "linked_events": [],
  "extents": [],
  "dates": [
    {
      "lock_version": 0,
      "expression": "undated",
      "created_by": "admin",
      "last_modified_by": "admin",
      "create_time": "2015-08-11T21:43:55Z",
      "system_mtime": "2015-08-11T21:43:55Z",
      "user_mtime": "2015-08-11T21:43:55Z",
      "date_type": "inclusive",
      "label": "creation",
      "jsonmodel_type": "date"
    }
  ],
  "external_documents": [],
  "rights_statements": [],
  "linked_agents": [],
  "instances": [
    {
      "lock_version": 0,
      "created_by": "admin",
      "last_modified_by": "admin",
      "create_time": "2015-08-11T21:43:55Z",
      "system_mtime": "2015-08-11T21:43:55Z",
      "user_mtime": "2015-08-11T21:43:55Z",
      "instance_type": "Realia",
      "jsonmodel_type": "instance",
      "is_representative": false,
      "sub_container": {
        "lock_version": 0,
        "created_by": "admin",
        "last_modified_by": "admin",
        "create_time": "2017-01-06T22:28:29Z",
        "system_mtime": "2017-01-06T22:28:29Z",
        "user_mtime": "2017-01-06T22:28:29Z",
        "jsonmodel_type": "sub_container",
        "top_container": {
          "ref": "/repositories/3/top_containers/1573"
        }
      },
      "container": {
        "type_1": "box",
        "indicator_1": "Artifacts 2",
        "barcode_1": "X030866782",
        "container_locations": [],
        "lock_version": 1
      }
    }
  ],
  "notes": [],
  "uri": "/repositories/3/archival_objects/256",
  "repository": {
    "ref": "/repositories/3"
  },
  "resource": {
    "ref": "/repositories/3/resources/11"
  },
  "has_unpublished_ancestor": false
}



But as I noted previously, I don?t see the significant difference in the data in 1.4.2 that was migrated that would account for one failing and the other succeeding.


( It appears that there are other records causing errors that don?t necessarily fit this same pattern. )

But the fact that this info is missing in the 1.5.1 migration does suggest it?s not a 1.5.2 only bug, but a problem with the container migration in earlier versions that is just made more visible by some 1.5.2 changes.


? Steve.



On Jan 12, 2017, at 11:39 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com<mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:


Hi,

It looks like the problem John is seeing with the indexer failing after upgrading to 1.5.2 is caused by an issue with a record following the container conversion. I?m following up with John off-list on the specifics of his problem. Hopefully we?ll be able to confirm this when we get to a resolution.

The container management upgrade has been the source of quite a few bugs and it is on our radar for review.


Cheers,
James



On Jan 13, 2017, at 1:30 AM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu<mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:

Yes, thank you,
I sent my data to you off-list.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org%3cmailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of James Bullen
Sent: Wednesday, January 11, 2017 6:56 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org%3cmailto:archivesspace_users_group at lyralists.lyrasis.org>>>
Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2


Hi John and Steve,

Can either of you send some sample data that surfaces this bug?


Cheers,
James


On Jan 12, 2017, at 8:17 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:


After seeing this message, I tried 1.5.2 on my Mac (10.11.6) laptop and I?m also seeing the same undefined method `related_records' for nil:NilClass error, whether or not I do an intervening ( and successful, BTW ) update to 1.5.1.
Reindexing never seems to progress and so browse resources never shows any records.


? Steve Majewski



On Jan 11, 2017, at 1:58 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu<mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:

Folks,

I am testing archivesspace 1.5.2 on CentOS 6, using a copy of our 1.4.2 production database.
Wondering why it seems like the indexer is taking so long to finish, I am seeing this in the archivesspace.out log, which makes me think the indexer is caught in an endless loop:

Keep seeing the SAME indexer messages over and over again:
~~~ Indexed 1475 of 1941 accession records in repository 3 ( added 25 records in  8229.0ms ) ~~~ ~~~ Indexed 1500 of 1941 accession records in repository 3 ( added 25 records in  5251.0ms ) ~~~

And then,

E, [2017-01-11T13:41:10.740000 #32733] ERROR -- : Thread-6445852: Unhandled exception!
E, [2017-01-11T13:41:10.741000 #32733] ERROR -- :
undefined method `related_records' for nil:NilClass /usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'
/usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'
/usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'
org/jruby/RubyHash.java:1341:in `each'

And then seems to start indexing the same data over again:
~~~ Indexed 50 of 1941 accession records in repository 3 ( added 25 records in  11153.0ms ) ~~~ ~~~ Indexed 75 of 1941 accession records in repository 3 ( added 25 records in  10051.0ms ) ~~~ ~~~ Indexed 100 of 1941 accession records in repository 3 ( added 25 records in  9558.0ms ) ~~~

Kind of looks like the indexer errors on ?something? then, tries to reindex the same accession records over and over again. I had followed the advice here:https://github.com/archivesspace/archivesspace/blob/master/UPGRADING_1.5.0.md#conversion<http://github.com/archivesspace/archivesspace/blob/master/UPGRADING_1.5.0.md#conversion>
before starting archivesspace, that is, ?delete your Solr index files to start with a fresh index?.

Any help is appreciated.
Thanks,
John H
NMU

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



!DSPAM:587793334611909212977! _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group


!DSPAM:587793334611909212977!

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

!DSPAM:587948af109451970717657!
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group


!DSPAM:587948af109451970717657!

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

<7ebc58861f8c38997d24d1316e9276ec>_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170323/1bde7825/attachment.html>

From sdm7g at eservices.virginia.edu  Fri Mar 24 11:33:10 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Fri, 24 Mar 2017 15:33:10 +0000
Subject: [Archivesspace_Users_Group] public or public-new in 2.0 [was:
	ArchivesSpace Update - March 2017]
In-Reply-To: <SN1PR08MB1406DE91425B31D3FDB37898F12C0@SN1PR08MB1406.namprd08.prod.outlook.com>
References: <SN1PR08MB1406DE91425B31D3FDB37898F12C0@SN1PR08MB1406.namprd08.prod.outlook.com>
Message-ID: <E826C9DE-B1F2-4301-9E75-E22864ABC96D@eservices.virginia.edu>


In the current code base, choosing to run public or public-new interface is a build option.
Is the plan for the release to bundle both for side-by-side testing and evaluation, and allow turning one off in the config file, or will this still be a custom build option ?

( I?m suggesting the former, BTW, but wondering what others preference is. )


? Steve Majewski



On Mar 6, 2017, at 12:21 PM, Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> wrote:


The next release of ArchivesSpace will reflect significant improvements in the underlying technology for the application, including upgrades to Rails 5 and JRuby 9.1.x. It will also feature the beta of the new public interface. To reflect the significance of these changes, the next version will be numbered 2.0.0. If you are looking ahead and thinking about IT resources needed for the 2.0.0 upgrade, please keep in mind that these changes will affect plugins and some local modifications. We?ll provide more guidance about how to adapt your plugins and modifications as we get closer to the final release. Also, this upgrade will require a complete re-index of your database. More information about 2.0.0 will be shared as the month progresses and we will be holding a webinar close to the time of the release that highlights the changes from a user and technological standpoint.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170324/8893c996/attachment.html>

From lsather at hagley.org  Mon Mar 27 11:11:04 2017
From: lsather at hagley.org (Laurie Sather)
Date: Mon, 27 Mar 2017 15:11:04 +0000
Subject: [Archivesspace_Users_Group] View all repositories?
Message-ID: <CO2PR16MB01238234023F9E56A0E3AB73C5330@CO2PR16MB0123.namprd16.prod.outlook.com>

Hi,

We just did a test migration from AT to ArchivesSpace.

We have 3 different collecting departments, so we have 3 different repositories set up in AT and now AS.

In AT - I can view all of the Accessions or Resource Records that are in AT from all of the repositories.

Is there a way to do this in AS? At the moment I am only able to see all accessions or all resource records by repository - this is very frustrating and difficult to work with. Does anyone know how to fix this?

Thank you!
Laurie

Laurie Sather, MA, MLIS, CA
Audiovisual and Digital Archivist
Audiovisual Collections and Digital Initiatives Department
Hagley Museum and Library
PO Box 3630
Wilmington, DE 19807-0630
Telephone: 302-658-2400 ext. 277
Email: lsather at hagley.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170327/a44a4f26/attachment-0001.html>

From trthorn2 at ncsu.edu  Mon Mar 27 14:28:25 2017
From: trthorn2 at ncsu.edu (Trevor Thornton)
Date: Mon, 27 Mar 2017 14:28:25 -0400
Subject: [Archivesspace_Users_Group] named processes on Linux?
Message-ID: <CA+SdyS0U_3owzgd-5eFXF=kYLWF1NOj0GPgBA89GwmhUC=BYxA@mail.gmail.com>

Is there a way to start ArchivesSpace on Linux such that the processes that
it spawns have names other than 'java' (for monitoring purposes)?

-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170327/7439801d/attachment.html>

From flannon at nyu.edu  Mon Mar 27 14:43:24 2017
From: flannon at nyu.edu (Flannon Jackson)
Date: Mon, 27 Mar 2017 14:43:24 -0400
Subject: [Archivesspace_Users_Group] named processes on Linux?
In-Reply-To: <CA+SdyS0U_3owzgd-5eFXF=kYLWF1NOj0GPgBA89GwmhUC=BYxA@mail.gmail.com>
References: <CA+SdyS0U_3owzgd-5eFXF=kYLWF1NOj0GPgBA89GwmhUC=BYxA@mail.gmail.com>
Message-ID: <CAJ2fXCPh=+Db7nMjUfG4-H6CamNgMbeKrgTRtUJj-5-WQfyj_w@mail.gmail.com>

The archivespace java process should also have the string
"archivesspace-daemon" in the process name, so you could track it by that.
Alternatively, the process id for the current archivesspace process is in
<archivessapce home>/data/..archivesspace.pid, so you could use the pid to
track the process.

-f

On Mon, Mar 27, 2017 at 2:28 PM, Trevor Thornton <trthorn2 at ncsu.edu> wrote:

> Is there a way to start ArchivesSpace on Linux such that the processes
> that it spawns have names other than 'java' (for monitoring purposes)?
>
> --
> Trevor Thornton
> Applications Developer, Digital Library Initiatives
> North Carolina State University Libraries
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170327/2a877c84/attachment.html>

From trthorn2 at ncsu.edu  Mon Mar 27 15:09:29 2017
From: trthorn2 at ncsu.edu (Trevor Thornton)
Date: Mon, 27 Mar 2017 15:09:29 -0400
Subject: [Archivesspace_Users_Group] named processes on Linux?
In-Reply-To: <CAJ2fXCPh=+Db7nMjUfG4-H6CamNgMbeKrgTRtUJj-5-WQfyj_w@mail.gmail.com>
References: <CA+SdyS0U_3owzgd-5eFXF=kYLWF1NOj0GPgBA89GwmhUC=BYxA@mail.gmail.com>
 <CAJ2fXCPh=+Db7nMjUfG4-H6CamNgMbeKrgTRtUJj-5-WQfyj_w@mail.gmail.com>
Message-ID: <CA+SdyS0MuZTZuMZD0zbnF1keRGPLnc5pCBDY=tjeQAB-Jj6knA@mail.gmail.com>

Thanks. I see "archivesspace-daemon" in the script but I can't find it on
the system or in the logs. I do see the pid file so maybe we can work with
that.

On Mon, Mar 27, 2017 at 2:43 PM, Flannon Jackson <flannon at nyu.edu> wrote:

> The archivespace java process should also have the string
> "archivesspace-daemon" in the process name, so you could track it by that.
> Alternatively, the process id for the current archivesspace process is in
> <archivessapce home>/data/..archivesspace.pid, so you could use the pid
> to track the process.
>
> -f
>
> On Mon, Mar 27, 2017 at 2:28 PM, Trevor Thornton <trthorn2 at ncsu.edu>
> wrote:
>
>> Is there a way to start ArchivesSpace on Linux such that the processes
>> that it spawns have names other than 'java' (for monitoring purposes)?
>>
>> --
>> Trevor Thornton
>> Applications Developer, Digital Library Initiatives
>> North Carolina State University Libraries
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170327/4fc938d7/attachment.html>

From sdm7g at eservices.virginia.edu  Mon Mar 27 15:11:06 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Mon, 27 Mar 2017 19:11:06 +0000
Subject: [Archivesspace_Users_Group] named processes on Linux?
In-Reply-To: <CAJ2fXCPh=+Db7nMjUfG4-H6CamNgMbeKrgTRtUJj-5-WQfyj_w@mail.gmail.com>
References: <CA+SdyS0U_3owzgd-5eFXF=kYLWF1NOj0GPgBA89GwmhUC=BYxA@mail.gmail.com>
 <CAJ2fXCPh=+Db7nMjUfG4-H6CamNgMbeKrgTRtUJj-5-WQfyj_w@mail.gmail.com>
Message-ID: <8FEF3DBF-7C95-4F2C-8088-8EB915D5C845@eservices.virginia.edu>


On Mar 27, 2017, at 2:43 PM, Flannon Jackson <flannon at nyu.edu<mailto:flannon at nyu.edu>> wrote:

The archivespace java process should also have the string "archivesspace-daemon" in the process name, so you could track it by that.  Alternatively, the process id for the current archivesspace process is in <archivessapce home>/data/..archivesspace.pid, so you could use the pid to track the process.

-f


You could also create an archivesspace user to run servers under.
Set environment variable ARCHIVESSPACE_USER before running the startup script, or edit the script to make that user the default.

? Steve.


On Mon, Mar 27, 2017 at 2:28 PM, Trevor Thornton <trthorn2 at ncsu.edu<mailto:trthorn2 at ncsu.edu>> wrote:
Is there a way to start ArchivesSpace on Linux such that the processes that it spawns have names other than 'java' (for monitoring purposes)?

--
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries

_______________________________________________
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


_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170327/13e4b184/attachment.html>

From smithkr at mit.edu  Tue Mar 28 16:12:21 2017
From: smithkr at mit.edu (Kari R Smith)
Date: Tue, 28 Mar 2017 20:12:21 +0000
Subject: [Archivesspace_Users_Group] LYRASIS hosted Archivesspace and
	Archivematica users
Message-ID: <29F559819ACA9A4FBF208407D4B63ABB010485A57A@OC11expo28.exchange.mit.edu>

Hello,
I'm looking for someone who has their ArchivesSpace instance hosted by LYRASIS and also uses Archivematica. I'm having trouble with my AS connection in the Archivematica Admin settings and am hoping to compare.

Thanks!

Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/  @karirene69

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170328/23028f29/attachment.html>

From james at hudmol.com  Tue Mar 28 23:35:25 2017
From: james at hudmol.com (James Bullen)
Date: Wed, 29 Mar 2017 14:35:25 +1100
Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
In-Reply-To: <c79e089e2fd74c369c9aaa00b7a3f35e@MB7.byu.local>
References: <c79e089e2fd74c369c9aaa00b7a3f35e@MB7.byu.local>
Message-ID: <E6419EFE-CFAC-41C5-8A63-7D68E11186AD@hudmol.com>


Hi Brent,

Sorry for the slow reply. From memory this is caused by bad instance records left around after certain operations on  digital objects. The bug that caused this has been fixed, but you may still have some of these bad records lying around.

The problem records are digital object type instances that don?t have a link to a digital object. This SQL will return any such records:

select i.* from instance i
left join instance_do_link_rlshp r on i.id = r.instance_id
left join enumeration_value e on i.instance_type_id = e.id
where instance_type_id = 349 and r.id is null
and e.value = 'digital_object';

If that query returns any rows, then just delete them. Hopefully that will fix the problem.


Cheers,
James



> On Mar 23, 2017, at 9:00 AM, Brent Ellingson <brent_ellingson at byu.edu> wrote:
> 
> We are in the process of upgrading our site from 1.4.2 to 1.5.3 and we are seeing a similar error as has been described in this thread. We are seeing the error below and continued looping of the indexer trying to index the archival objects.
>  
> ~~~ Indexed 1225 of 67886 archival_object records in repository 2 ( added 25 records in  6399.0ms ) ~~~
> ~~~ Indexed 1250 of 67886 archival_object records in repository 2 ( added 25 records in  5488.0ms ) ~~~
> E, [2017-03-16T16:53:51.425000 #779] ERROR -- : Thread-2392462: Unhandled exception!
> E, [2017-03-16T16:53:51.425000 #779] ERROR -- :
> undefined method `related_records' for nil:NilClass
> /opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'
> /opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'
> /opt/archivesspace-1.5.3/archivesspace/data/tmp/jetty-0.0.0.0-9089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'
> org/jruby/RubyHash.java:1341:in `each'
> org/jruby/RubyEnumerable.java:757:in `map'
>  
> Does a resolution to this issue exist?
> How do I find what the offending set of data is causing the problem?
> How do I proceed?
>  
> Thank you for your help.
>  
> Regards,
> __________________________
> Brent Ellingson
> Sr. Software Engineer
> BYU Library
> 801-422-6148
>  
>  
> Date: Mon, 23 Jan 2017 19:54:53 +0000
> From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu>>
> To: Archivesspace Users Group
>                 <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
> Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
> Message-ID:
>                 <1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu <mailto:1B0EA75C-EE19-492A-B057-FBAEFBBFB880 at eservices.virginia.edu>>
> Content-Type: text/plain; charset="utf-8"
>  
>  
> The first two issues appear to be due to trailing spaces in some of the container barcodes.
> Top containers have already been created for barcodes without trailing space, and so it appears that the barcodes don?t match.
>  
>  
>  
> On Jan 20, 2017, at 3:49 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:
>  
>  
> On Jan 13, 2017, at 6:15 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com <mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:
>  
>  
> Hi Steve,
>  
> That fits the pattern I?m seeing in John?s data. Have you checked the container conversion log for any errors relating to that record?
>  
>  
> Cheers,
> James
>  
>  
>  
> Just re-did migration from 1.4.2 to 1.5.1 again, and I?m inspecting the logs.
>  
> Yes, archival_objects/255 is on that list.
>  
> error,message,url
> JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331 <http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/331>>
> JSONModel::ValidationException,barcode_1 -- Mismatch when mapping between barcode and barcode_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059 <http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/2059>>
> JSONModel::ValidationException,indicator_1 -- Mismatch when mapping between indicator and indicator_1,http://UL-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255<http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255 <http://ul-sdm7g-mbp.local/resolve/readonly?uri=/repositories/3/archival_objects/255>>
>  
>  
>  
> I need to inspect the other repo logs and see if all of the ones that break are getting caught, but it looks likely.
>  
> I?m trying to interpret what exactly those messages are complaining about.
> Do those error messages and object dumps mean anything to you off the bat?
>  
> ? Steve.
>  
>  
> On Jan 14, 2017, at 8:37 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:
>  
>  
> It looks like the indexer gives and error because the backend is getting an error turning the SQL model into a JSON model.
>  
> For some of the archival objects that are failing to index, the significant difference is that they do not have a sub_container in their instance. Trying to access the json from the backend in 1.5.2 just yields an error message, but going back to test 1.5.1 migration:
>  
> [ This is json from the same screen capture in my previous message. ]
>  
> archival_object 255 ( which causes error on index )
>  
> {
>   "lock_version": 0,
>   "position": 17,
>   "publish": true,
>   "ref_id": "aspace_22a35d6a6ee59ac454ca8f35232b0b40",
>   "title": "Buttons and uniform parts, souvenirs, and medals",
>   "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",
>   "restrictions_apply": false,
>   "created_by": "admin",
>   "last_modified_by": "admin",
>   "create_time": "2015-08-11T21:43:55Z",
>   "system_mtime": "2017-01-06T22:25:38Z",
>   "user_mtime": "2015-08-11T21:43:55Z",
>   "suppressed": false,
>   "level": "file",
>   "jsonmodel_type": "archival_object",
>   "external_ids": [],
>   "subjects": [],
>   "linked_events": [],
>   "extents": [],
>   "dates": [
>     {
>       "lock_version": 0,
>       "expression": "undated",
>       "created_by": "admin",
>       "last_modified_by": "admin",
>       "create_time": "2015-08-11T21:43:55Z",
>       "system_mtime": "2015-08-11T21:43:55Z",
>       "user_mtime": "2015-08-11T21:43:55Z",
>       "date_type": "inclusive",
>       "label": "creation",
>       "jsonmodel_type": "date"
>     }
>   ],
>   "external_documents": [],
>   "rights_statements": [],
>   "linked_agents": [],
>   "instances": [
>     {
>       "lock_version": 0,
>       "created_by": "admin",
>       "last_modified_by": "admin",
>       "create_time": "2015-08-11T21:43:55Z",
>       "system_mtime": "2015-08-11T21:43:55Z",
>       "user_mtime": "2015-08-11T21:43:55Z",
>       "instance_type": "Realia",
>       "jsonmodel_type": "instance",
>       "is_representative": false,
>       "container": {
>         "lock_version": 0,
>         "indicator_1": "Artifacts 1",
>         "barcode_1": "X030898965",
>         "created_by": "admin",
>         "last_modified_by": "admin",
>         "create_time": "2015-08-11T21:43:55Z",
>         "system_mtime": "2016-11-22T16:58:54Z",
>         "user_mtime": "2015-08-11T21:43:55Z",
>         "type_1": "box",
>         "jsonmodel_type": "container",
>         "container_locations": []
>       }
>     }
>   ],
>   "notes": [],
>   "uri": "/repositories/3/archival_objects/255",
>   "repository": {
>     "ref": "/repositories/3"
>   },
>   "resource": {
>     "ref": "/repositories/3/resources/11"
>   },
>   "has_unpublished_ancestor": false
> }
>  
> archival_object 256: ( indexes successfully, once 255 is deleted. )
>  
> {
>   "lock_version": 0,
>   "position": 18,
>   "publish": false,
>   "ref_id": "aspace_15da7f2a9b0184a65b1280ae05a7598a",
>   "title": "Buttons and uniform parts, souvenirs, and medals",
>   "display_string": "Buttons and uniform parts, souvenirs, and medals, undated",
>   "restrictions_apply": false,
>   "created_by": "admin",
>   "last_modified_by": "admin",
>   "create_time": "2015-08-11T21:43:55Z",
>   "system_mtime": "2017-01-06T22:25:38Z",
>   "user_mtime": "2015-08-11T21:43:55Z",
>   "suppressed": false,
>   "level": "file",
>   "jsonmodel_type": "archival_object",
>   "external_ids": [],
>   "subjects": [],
>   "linked_events": [],
>   "extents": [],
>   "dates": [
>     {
>       "lock_version": 0,
>       "expression": "undated",
>       "created_by": "admin",
>       "last_modified_by": "admin",
>       "create_time": "2015-08-11T21:43:55Z",
>       "system_mtime": "2015-08-11T21:43:55Z",
>       "user_mtime": "2015-08-11T21:43:55Z",
>       "date_type": "inclusive",
>       "label": "creation",
>       "jsonmodel_type": "date"
>     }
>   ],
>   "external_documents": [],
>   "rights_statements": [],
>   "linked_agents": [],
>   "instances": [
>     {
>       "lock_version": 0,
>       "created_by": "admin",
>       "last_modified_by": "admin",
>       "create_time": "2015-08-11T21:43:55Z",
>       "system_mtime": "2015-08-11T21:43:55Z",
>       "user_mtime": "2015-08-11T21:43:55Z",
>       "instance_type": "Realia",
>       "jsonmodel_type": "instance",
>       "is_representative": false,
>       "sub_container": {
>         "lock_version": 0,
>         "created_by": "admin",
>         "last_modified_by": "admin",
>         "create_time": "2017-01-06T22:28:29Z",
>         "system_mtime": "2017-01-06T22:28:29Z",
>         "user_mtime": "2017-01-06T22:28:29Z",
>         "jsonmodel_type": "sub_container",
>         "top_container": {
>           "ref": "/repositories/3/top_containers/1573"
>         }
>       },
>       "container": {
>         "type_1": "box",
>         "indicator_1": "Artifacts 2",
>         "barcode_1": "X030866782",
>         "container_locations": [],
>         "lock_version": 1
>       }
>     }
>   ],
>   "notes": [],
>   "uri": "/repositories/3/archival_objects/256",
>   "repository": {
>     "ref": "/repositories/3"
>   },
>   "resource": {
>     "ref": "/repositories/3/resources/11"
>   },
>   "has_unpublished_ancestor": false
> }
>  
>  
>  
> But as I noted previously, I don?t see the significant difference in the data in 1.4.2 that was migrated that would account for one failing and the other succeeding.
>  
>  
> ( It appears that there are other records causing errors that don?t necessarily fit this same pattern. )
>  
> But the fact that this info is missing in the 1.5.1 migration does suggest it?s not a 1.5.2 only bug, but a problem with the container migration in earlier versions that is just made more visible by some 1.5.2 changes.
>  
>  
> ? Steve.
>  
>  
>  
> On Jan 12, 2017, at 11:39 PM, James Bullen <james at hudmol.com<mailto:james at hudmol.com <mailto:james at hudmol.com%3cmailto:james at hudmol.com>>> wrote:
>  
>  
> Hi,
>  
> It looks like the problem John is seeing with the indexer failing after upgrading to 1.5.2 is caused by an issue with a record following the container conversion. I?m following up with John off-list on the specifics of his problem. Hopefully we?ll be able to confirm this when we get to a resolution.
>  
> The container management upgrade has been the source of quite a few bugs and it is on our radar for review.
>  
>  
> Cheers,
> James
>  
>  
>  
> On Jan 13, 2017, at 1:30 AM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu <mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:
>  
> Yes, thank you,
> I sent my data to you off-list.
>  
> John H
> NMU
>  
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org%3cmailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of James Bullen
> Sent: Wednesday, January 11, 2017 6:56 PM
> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org%3cmailto:archivesspace_users_group at lyralists.lyrasis.org>>>
> Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2
>  
>  
> Hi John and Steve,
>  
> Can either of you send some sample data that surfaces this bug?
>  
>  
> Cheers,
> James
>  
>  
> On Jan 12, 2017, at 8:17 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu%3cmailto:sdm7g at eservices.virginia.edu>>> wrote:
>  
>  
> After seeing this message, I tried 1.5.2 on my Mac (10.11.6) laptop and I?m also seeing the same undefined method `related_records' for nil:NilClass error, whether or not I do an intervening ( and successful, BTW ) update to 1.5.1.
> Reindexing never seems to progress and so browse resources never shows any records.
>  
>  
> ? Steve Majewski
>  
>  
>  
> On Jan 11, 2017, at 1:58 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu <mailto:jhamblet at nmu.edu%3cmailto:jhamblet at nmu.edu>>> wrote:
>  
> Folks,
>  
> I am testing archivesspace 1.5.2 on CentOS 6, using a copy of our 1.4.2 production database.
> Wondering why it seems like the indexer is taking so long to finish, I am seeing this in the archivesspace.out log, which makes me think the indexer is caught in an endless loop:
>  
> Keep seeing the SAME indexer messages over and over again:
> ~~~ Indexed 1475 of 1941 accession records in repository 3 ( added 25 records in  8229.0ms ) ~~~ ~~~ Indexed 1500 of 1941 accession records in repository 3 ( added 25 records in  5251.0ms ) ~~~
>  
> And then,
>  
> E, [2017-01-11T13:41:10.740000 #32733] ERROR -- : Thread-6445852: Unhandled exception!
> E, [2017-01-11T13:41:10.741000 #32733] ERROR -- :
> undefined method `related_records' for nil:NilClass /usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:64:in `top_container'
> /usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:24:in `type_1'
> /usr/local/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/subcontainer_to_aspace_json_mapper.rb:14:in `to_hash'
> org/jruby/RubyHash.java:1341:in `each'
>  
> And then seems to start indexing the same data over again:
> ~~~ Indexed 50 of 1941 accession records in repository 3 ( added 25 records in  11153.0ms ) ~~~ ~~~ Indexed 75 of 1941 accession records in repository 3 ( added 25 records in  10051.0ms ) ~~~ ~~~ Indexed 100 of 1941 accession records in repository 3 ( added 25 records in  9558.0ms ) ~~~
>  
> Kind of looks like the indexer errors on ?something? then, tries to reindex the same accession records over and over again. I had followed the advice here:https://github.com/archivesspace/archivesspace/blob/master/UPGRADING_1.5.0.md#conversion <https://github.com/archivesspace/archivesspace/blob/master/UPGRADING_1.5.0.md#conversion>
> before starting archivesspace, that is, ?delete your Solr index files to start with a fresh index?.
>  
> Any help is appreciated.
> Thanks,
> John H
> NMU
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
>  
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
>  
> !DSPAM:587793334611909212977!
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
> !DSPAM:587948af109451970717657!
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
>  
> !DSPAM:587948af109451970717657!
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
> <7ebc58861f8c38997d24d1316e9276ec>_______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org%3cmailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>  
> !DSPAM:58d2f405237347847715625! _______________________________________________
> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
> 
> 
> !DSPAM:58d2f405237347847715625!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/0185f839/attachment.html>

From hawkpf at miamioh.edu  Wed Mar 29 13:26:37 2017
From: hawkpf at miamioh.edu (Hawk, Patrick)
Date: Wed, 29 Mar 2017 13:26:37 -0400
Subject: [Archivesspace_Users_Group] Failure in periodic indexer worker
	thread
In-Reply-To: <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
 <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>
Message-ID: <CAH_HnmW5WsgROH3Jy9kuHRA2Y-GxHogehUw8JK=DVjG3iV3pSA@mail.gmail.com>

Steve,

I'm attaching a screen capture.  The barcode_1 field needs to be unique in
the table container?

On Thu, Mar 16, 2017 at 1:10 PM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu> wrote:

>
> I interpret that error message as saying that you are trying to assign the
> same barcode ( "Miami University Archives (Western College for Women
> Collection)? ) to ?box 1? and ?box 2? (type + indicator). Barcodes must be
> unique. A collection name is not likely to be unique if there are more than
> one containers. Typically, these are machine scannable barcode numbers.  If
> you really want to use the collection name here, you could maybe append the
> box numbers to the ends of both, making them unique.
>
>
> ? Steve.
>
>
> On Mar 16, 2017, at 12:10 PM, Hawk, Patrick <hawkpf at miamioh.edu> wrote:
>
> John,
> Do you know which two accessions you had to modify?
>
> Also, this is what I see in archivesspace/logs/archivesspace.out
>
> <:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping
> between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer
> @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1,
> :barcode=>"Miami University Archives (Western College for Women
> Collection)", :ils_holding_id=>nil, :ils_item_id=>nil,
> :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX",
> :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC,
> :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48
> UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0,
> "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western
> College for Women Collection)", "container_extent"=>"1.00",
> "created_by"=>"XXXX", "last_modified_by"=>"XXXX",
> "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z",
> "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box",
> "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container",
> "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31",
> "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01
> UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>
>
>
>
> On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu>
> wrote:
>
>> Hello!
>>
>>
>>
>> That thread below was us, Northern Michigan University.
>>
>> Looking in the container conversion log, was this error:
>>
>>
>>
>> Error:
>>
>> JSONModel::ValidationException
>>
>>
>>
>> Message:
>>
>> indicator_1 -- Mismatch when mapping between indicator and indicator_1
>>
>>
>>
>> James Bullen took a look at our log and determined that there was a
>> barcode
>>
>> uniqueness problem between two accessions. So we cleaned that up and sure
>> enough,
>>
>> that was it. We re-ran the conversion and the indexer did not have any
>> problems.
>>
>>
>>
>> Hope this helps you.
>>
>>
>>
>> John H
>>
>> NMU
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Hawk,
>> Patrick
>> *Sent:* Tuesday, March 14, 2017 3:27 PM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Failure in periodic indexer
>> worker thread
>>
>>
>>
>> Steve,
>> The url you linked would be the same issue, so yes the indexer tries to
>> index the same items over and over...  I'll have to inspect the records to
>> see what is causing the migration to fail.
>>
>>
>>
>> On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <
>> sdm7g at eservices.virginia.edu> wrote:
>>
>>
>>
>> Check for errors in the container conversion batch job log files.
>>
>>
>>
>> Does the indexer appear to keep trying to reindex the same records over
>> and over ?
>>
>>
>>
>> See previous thread:
>>
>> http://lyralists.lyrasis.org/pipermail/archivesspace_users_g
>> roup/2017-January/004370.html
>>
>>
>>
>> ? Steve Majewski
>>
>>
>>
>>
>>
>>
>>
>> On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu> wrote:
>>
>>
>>
>> Hello,
>>
>> I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having
>> issues getting my content to fully load.  I followed the instructions here:
>> http://archivesspace.github.io/archivesspace/user/upgrading-
>> to-a-new-release-of-archivesspace/.  I removed the directory
>> /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index
>> as the directions stated I should do when upgrading to 1.5.0.  I also ran
>> the setup-database.sh without issue.
>>
>>
>>
>> However, I receive the following error:  Failure in periodic indexer
>> worker thread: {"error":"undefined method `related_records' for
>> nil:NilClass"} in the archivesspace.out file.  At this point the logs
>> suggest that all items have been re-indexed but my content does not fully
>> load.  Any suggestions?
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>>
>> --
>>
>> Patrick Hawk
>>
>> King Library Systems
>>
>> King Library Room  314
>>
>> 513-529-6122 <(513)%20529-6122>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
>
> Patrick Hawk
>
>
> King Library Systems
>
> King Library Room  314
>
> 513-529-6122 <(513)%20529-6122>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 

Patrick Hawk


King Library Systems

King Library Room  314

513-529-6122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/4bb3544e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AS.PNG
Type: image/png
Size: 16860 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/4bb3544e/attachment.png>

From sdm7g at eservices.virginia.edu  Wed Mar 29 14:21:22 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 29 Mar 2017 18:21:22 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic indexer
	worker	thread
In-Reply-To: <CAH_HnmW5WsgROH3Jy9kuHRA2Y-GxHogehUw8JK=DVjG3iV3pSA@mail.gmail.com>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
 <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>
 <CAH_HnmW5WsgROH3Jy9kuHRA2Y-GxHogehUw8JK=DVjG3iV3pSA@mail.gmail.com>
Message-ID: <DC555C35-4E53-46D5-A23F-C2BBCB4AFC25@eservices.virginia.edu>


On Mar 29, 2017, at 1:26 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Steve,

I'm attaching a screen capture.  The barcode_1 field needs to be unique in the table container?



That?s my understanding, although I?m not certain if they have to be globally unique or just unique within that resource. ( I expect the intention is for them to be globally unique, but I?m not sure if they actually check beyond the current resource. ) I?m not sure, but I don?t think a barcode is required, so another option may be to just delete those barcodes. Or, as I initially suggested, append ?box 1?, ?box 2? , etc. to your existing barcodes to make them unique.


I believe there was some discussion relating to these issues in the 1.5.0 release webinar, probably in Noah?s talks and notes:

http://archivesspace.org/recording-and-slides-for-v1-5-0-release-webinar/

If you haven?t already, you should check it out, as it?s the easiest intro the what?s involved in the migration. ( I don?t think the upgrading docs in the distribution explain the terminology and background sufficiently. )


? Steve.


On Thu, Mar 16, 2017 at 1:10 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

I interpret that error message as saying that you are trying to assign the same barcode ( "Miami University Archives (Western College for Women Collection)? ) to ?box 1? and ?box 2? (type + indicator). Barcodes must be unique. A collection name is not likely to be unique if there are more than one containers. Typically, these are machine scannable barcode numbers.  If you really want to use the collection name here, you could maybe append the box numbers to the ends of both, making them unique.


? Steve.


On Mar 16, 2017, at 12:10 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

John,
Do you know which two accessions you had to modify?

Also, this is what I see in archivesspace/logs/archivesspace.out

<:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami University Archives (Western College for Women Collection)", :ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0, "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western College for Women Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX", "last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z", "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box", "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container", "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31", "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01 UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>



On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu>> wrote:
Hello!

That thread below was us, Northern Michigan University.
Looking in the container conversion log, was this error:

Error:
JSONModel::ValidationException

Message:
indicator_1 -- Mismatch when mapping between indicator and indicator_1

James Bullen took a look at our log and determined that there was a barcode
uniqueness problem between two accessions. So we cleaned that up and sure enough,
that was it. We re-ran the conversion and the indexer did not have any problems.

Hope this helps you.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Hawk, Patrick
Sent: Tuesday, March 14, 2017 3:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

Steve,
The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here: http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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


_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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




--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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


_______________________________________________
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




--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122

<AS.PNG>_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/626a214f/attachment.html>

From sdm7g at eservices.virginia.edu  Wed Mar 29 14:27:41 2017
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Wed, 29 Mar 2017 18:27:41 +0000
Subject: [Archivesspace_Users_Group] Failure in periodic
	indexer	worker	thread
In-Reply-To: <DC555C35-4E53-46D5-A23F-C2BBCB4AFC25@eservices.virginia.edu>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
 <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>
 <CAH_HnmW5WsgROH3Jy9kuHRA2Y-GxHogehUw8JK=DVjG3iV3pSA@mail.gmail.com>
 <DC555C35-4E53-46D5-A23F-C2BBCB4AFC25@eservices.virginia.edu>
Message-ID: <8F4DD791-A2D3-4DB4-9507-37296B1C13EA@eservices.virginia.edu>

PS: There was also Mark Cooper?s container migration notes:
https://gist.github.com/mark-cooper/96892ab8734cf96a5a6ab0268107ab45

And some Yale screencasts:
http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement

? Steve.


On Mar 29, 2017, at 2:21 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:


On Mar 29, 2017, at 1:26 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Steve,

I'm attaching a screen capture.  The barcode_1 field needs to be unique in the table container?



That?s my understanding, although I?m not certain if they have to be globally unique or just unique within that resource. ( I expect the intention is for them to be globally unique, but I?m not sure if they actually check beyond the current resource. ) I?m not sure, but I don?t think a barcode is required, so another option may be to just delete those barcodes. Or, as I initially suggested, append ?box 1?, ?box 2? , etc. to your existing barcodes to make them unique.


I believe there was some discussion relating to these issues in the 1.5.0 release webinar, probably in Noah?s talks and notes:

http://archivesspace.org/recording-and-slides-for-v1-5-0-release-webinar/

If you haven?t already, you should check it out, as it?s the easiest intro the what?s involved in the migration. ( I don?t think the upgrading docs in the distribution explain the terminology and background sufficiently. )


? Steve.


On Thu, Mar 16, 2017 at 1:10 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

I interpret that error message as saying that you are trying to assign the same barcode ( "Miami University Archives (Western College for Women Collection)? ) to ?box 1? and ?box 2? (type + indicator). Barcodes must be unique. A collection name is not likely to be unique if there are more than one containers. Typically, these are machine scannable barcode numbers.  If you really want to use the collection name here, you could maybe append the box numbers to the ends of both, making them unique.


? Steve.


On Mar 16, 2017, at 12:10 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

John,
Do you know which two accessions you had to modify?

Also, this is what I see in archivesspace/logs/archivesspace.out

<:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami University Archives (Western College for Women Collection)", :ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0, "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western College for Women Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX", "last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z", "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box", "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container", "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31", "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01 UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>



On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu<mailto:jhamblet at nmu.edu>> wrote:
Hello!

That thread below was us, Northern Michigan University.
Looking in the container conversion log, was this error:

Error:
JSONModel::ValidationException

Message:
indicator_1 -- Mismatch when mapping between indicator and indicator_1

James Bullen took a look at our log and determined that there was a barcode
uniqueness problem between two accessions. So we cleaned that up and sure enough,
that was it. We re-ran the conversion and the indexer did not have any problems.

Hope this helps you.

John H
NMU

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Hawk, Patrick
Sent: Tuesday, March 14, 2017 3:27 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread

Steve,
The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.

On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

Check for errors in the container conversion batch job log files.

Does the indexer appear to keep trying to reindex the same records over and over ?

See previous thread:
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html

? Steve Majewski



On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu<mailto:hawkpf at miamioh.edu>> wrote:

Hello,

I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here:http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.

However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions?
_______________________________________________
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


_______________________________________________
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



--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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




--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122<tel:(513)%20529-6122>

_______________________________________________
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


_______________________________________________
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




--

Patrick Hawk

[http://miamioh.edu/images/ucm/resources/logos/jpg-web-res/email-FSL_186K.jpg]

King Library Systems

King Library Room  314

513-529-6122

<AS.PNG>_______________________________________________
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

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/f32b1363/attachment.html>

From christine.dibella at lyrasis.org  Wed Mar 29 14:30:51 2017
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Wed, 29 Mar 2017 18:30:51 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace release candidate
	available - v2.0.0-RC1
Message-ID: <SN1PR08MB1406CD65F62E938EB8D9453DF1350@SN1PR08MB1406.namprd08.prod.outlook.com>

Dear ArchivesSpace members,

We are pleased to announce that a release candidate - v2.0.0-RC1 (https://github.com/archivesspace/archivesspace/releases/tag/v2.0.0-RC1) - is now available for download and testing purposes. Version 2.0.0 of ArchivesSpace will be a major release, with many changes to the underlying technologies of the application as well as improved functionality in some key areas. Summary information about these changes is available at the release notes accompanying the release candidate. The changes include upgrading to Rails 5, better performance for background jobs and larger databases, a new way to reorder components in resources and digital objects, and remediation of issues with reports.  By default, this file will use the current public interface for ArchivesSpace. This release candidate features substantial work from our development partner, Hudson Molonglo (HM), as well as contributions from community members.

Public User Interface (PUI)
The release notes indicate that the new public interface beta is available if you/your system administrator make a change to an environmental variable. Instructions for doing so are in the release notes. Because the new public interface is a beta (i.e. not ready for production use) and is still being actively worked on in order to get as much of the requested functionality into it as possible by the June full release, you should not change this setting on your production server, even if you are not currently using the public interface. This is essentially a sneak preview of major functionality and we look forward to your feedback. The beta includes many of the most complex elements of this work, and more functionality, including the ability to print records to PDF, will be included in the June release. The new public interface reflects tireless work in this area led by Mark Custer of Yale University, and features input from our member working group participants and web firm Cherry Hill Company (who worked with the group in 2015), as well as development by HM (largely funded by Yale) and Harvard developers. Details on this work, including the wireframes and functionality that are guiding the development phase of this work, are available at https://archivesspace.atlassian.net/wiki/display/ADC/Public+Interface+Enhancement+Project.

Testing and Feedback
Please try out this release candidate the next few days and let us know if you experience any problems. If you use this release candidate with your own data, please note that a full index is required. Also, please note that running reports requires a MySQL database backend. You will not be able to run reports with the embedded database.

If you don't wish to download anything at this time, you can still test drive the release candidate on our test site, http://test.archivesspace.org, using the standard administrative login (admin/admin). (The test server uses the current public interface; if you want to check out the beta of the public interface, HM has a preview site up at http://pui.hudmol.com/.)

As many of the changes this time are larger than single issues in JIRA, we're asking people to provide feedback by emailing me directly. Since the changes are throughout the application, we encourage you to run through the areas of the application you use regularly and let us know if anything that was working previously appears not to be, or if anything described about the new functionality is not working as intended. If possible, please submit your feedback no later than April 12. We will determine an exact release date for 2.0.0 when we are confident in the testing results.

Thanks
Thanks to HM for all their work on this release candidate, to our community members that contributed code, to those on the Prioritization, Reports, and Testing sub-teams who identified and tested the many changes, and to the Public Interface Enhancement Project participants for their extensive and continuing efforts. If you have any questions, or if you notice any issues while testing, please let us know.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/4c8f6c53/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170329/4c8f6c53/attachment.jpg>

From james at hudmol.com  Wed Mar 29 20:31:48 2017
From: james at hudmol.com (James Bullen)
Date: Thu, 30 Mar 2017 11:31:48 +1100
Subject: [Archivesspace_Users_Group] Failure in periodic indexer	worker
 thread
In-Reply-To: <8F4DD791-A2D3-4DB4-9507-37296B1C13EA@eservices.virginia.edu>
References: <CAH_HnmUNLjTnqKvrkEwOqsxzTGR+3Lz7=9eibqKV-vMQ3Fpy-A@mail.gmail.com>
 <10B09366-1478-49A6-B1C1-FFBC15BB547D@eservices.virginia.edu>
 <CAH_HnmWiU+zZX2EXyv07+UWJOE2GZEQqM+7rgbOtM=Dh=NaQQA@mail.gmail.com>
 <3209f21eab7c4ce1aba859edf7f38d60@EX01.ads.nmu.edu>
 <CAH_HnmXWcdaaJ8vZB-xRxOv0q0m0DNp4breBLXodjn+tLVRJSg@mail.gmail.com>
 <3BF93CDE-1B84-48AC-A9F7-1F442B0CA406@eservices.virginia.edu>
 <CAH_HnmW5WsgROH3Jy9kuHRA2Y-GxHogehUw8JK=DVjG3iV3pSA@mail.gmail.com>
 <DC555C35-4E53-46D5-A23F-C2BBCB4AFC25@eservices.virginia.edu>
 <8F4DD791-A2D3-4DB4-9507-37296B1C13EA@eservices.virginia.edu>
Message-ID: <E96DB0F8-51FD-461B-B361-DB52A7DA9DB6@hudmol.com>


Hi Patrick,

This is a bit confusing because there are currently two container tables: ?container? and ?top_container?.

?container? is the old container table - ie from before the container management plugin was merged in.
?top_container? is the new container table - ie it was introduced as part of the container management merge.

The ?container? table should really have been dropped when the container management plugin was merged in, but that can?t be done yet because a bunch of code still depends on it, and there?s some cunning mapping that goes on between the two tables behind the scenes. It is on our list of priorities for the next major release (currently scheduled for June) to resolve this and a few other issues surrounding the container management merge.

So, to your question about barcodes:
container.barcode does not have a unique constraint.
top_container.barcode must be unique within a repository.

In the old container model, container records are nested sub-records, so many container records might refer to the same physical box. This means that is was not possible to have barcodes be unique. In the new container management model a top_container record represents a physical box, so it is possible to enforce unique barcodes in the database.

Hope that helps.


Cheers,
James


> On Mar 30, 2017, at 5:27 AM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu> wrote:
> 
> PS: There was also Mark Cooper?s container migration notes:
> https://gist.github.com/mark-cooper/96892ab8734cf96a5a6ab0268107ab45 <https://gist.github.com/mark-cooper/96892ab8734cf96a5a6ab0268107ab45>
> 
> And some Yale screencasts:
> http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement <http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement>
> 
> ? Steve. 
> 
> 
>> On Mar 29, 2017, at 2:21 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu>> wrote:
>> 
>>> 
>>> On Mar 29, 2017, at 1:26 PM, Hawk, Patrick <hawkpf at miamioh.edu <mailto:hawkpf at miamioh.edu>> wrote:
>>> 
>>> Steve,
>>> 
>>> I'm attaching a screen capture.  The barcode_1 field needs to be unique in the table container?
>>> 
>> 
>> 
>> That?s my understanding, although I?m not certain if they have to be globally unique or just unique within that resource. ( I expect the intention is for them to be globally unique, but I?m not sure if they actually check beyond the current resource.  ) I?m not sure, but I don?t think a barcode is required, so another option may be to just delete those barcodes. Or, as I initially suggested, append ?box 1?, ?box 2? , etc. to your existing barcodes to make them unique. 
>> 
>> 
>> I believe there was some discussion relating to these issues in the 1.5.0 release webinar, probably in Noah?s talks and notes:
>> 
>> http://archivesspace.org/recording-and-slides-for-v1-5-0-release-webinar/ <http://archivesspace.org/recording-and-slides-for-v1-5-0-release-webinar/>
>> 
>> If you haven?t already, you should check it out, as it?s the easiest intro the what?s involved in the migration. ( I don?t think the upgrading docs in the distribution explain the terminology and background sufficiently. ) 
>> 
>> 
>> ? Steve. 
>> 
>> 
>>> On Thu, Mar 16, 2017 at 1:10 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu>> wrote:
>>> 
>>> I interpret that error message as saying that you are trying to assign the same barcode ( "Miami University Archives (Western College for Women Collection)? ) to ?box 1? and ?box 2? (type + indicator). Barcodes must be unique. A collection name  is not likely to be unique if there are more than one containers. Typically, these are machine scannable barcode numbers.  If you really want to use the collection name here, you could maybe append the box numbers to the ends of both, making them unique. 
>>> 
>>> 
>>> ? Steve. 
>>> 
>>> 
>>>> On Mar 16, 2017, at 12:10 PM, Hawk, Patrick <hawkpf at miamioh.edu <mailto:hawkpf at miamioh.edu>> wrote:
>>>> 
>>>> John,
>>>> Do you know which two accessions you had to modify?
>>>> 
>>>> Also, this is what I see in archivesspace/logs/archivesspace.out
>>>> 
>>>> <:ValidationException: {:errors=>{"indicator_1"=>["Mismatch when mapping between indicator and indicator_1"]}, :object_context=>{:top_container=>#<TopContainer @values={:id=>2, :repo_id=>2, :lock_version=>0, :json_schema_version=>1, :barcode=>"Miami University Archives (Western College for Women Collection)", :ils_holding_id=>nil, :ils_item_id=>nil, :exported_to_ils=>nil, :indicator=>"1", :created_by=>"XXXX", :last_modified_by=>"XXXX", :create_time=>2017-03-15 20:01:48 UTC, :system_mtime=>2017-03-15 20:01:48 UTC, :user_mtime=>2017-03-15 20:01:48 UTC, :type_id=>318}>, :aspace_container=>{"lock_version"=>0, "indicator_1"=>"2", "barcode_1"=>"Miami University Archives (Western College for Women Collection)", "container_extent"=>"1.00", "created_by"=>"XXXX", "last_modified_by"=>"XXXX", "create_time"=>"2016-02-16T15:42:01Z", "system_mtime"=>"2016-11-15T18:16:09Z", "user_mtime"=>"2016-02-16T15:42:01Z", "type_1"=>"box", "container_extent_type"=>"Boxes", "jsonmodel_type"=>"container", "container_locations"=>[{"status"=>"current", "start_date"=>"1999-12-31", "system_mtime"=>2016-02-16 15:42:01 UTC, "user_mtime"=>2016-02-16 15:42:01 UTC, "ref"=>"/locations/8584"}], "type_id"=>318}}}>
>>>> 
>>>> 
>>>> 
>>>> On Tue, Mar 14, 2017 at 3:40 PM, Hambleton, John S <jhamblet at nmu.edu <mailto:jhamblet at nmu.edu>> wrote:
>>>> Hello!
>>>> 
>>>>  
>>>> 
>>>> That thread below was us, Northern Michigan University.
>>>> 
>>>> Looking in the container conversion log, was this error:
>>>> 
>>>>  
>>>> 
>>>> Error:
>>>> 
>>>> JSONModel::ValidationException
>>>> 
>>>>  
>>>> 
>>>> Message:
>>>> 
>>>> indicator_1 -- Mismatch when mapping between indicator and indicator_1
>>>> 
>>>>  
>>>> 
>>>> James Bullen took a look at our log and determined that there was a barcode
>>>> 
>>>> uniqueness problem between two accessions. So we cleaned that up and sure enough,
>>>> 
>>>> that was it. We re-ran the conversion and the indexer did not have any problems.
>>>> 
>>>>  
>>>> 
>>>> Hope this helps you.
>>>> 
>>>>  
>>>> 
>>>> John H
>>>> 
>>>> NMU
>>>> 
>>>>  
>>>> 
>>>> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Hawk, Patrick
>>>> Sent: Tuesday, March 14, 2017 3:27 PM
>>>> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
>>>> Subject: Re: [Archivesspace_Users_Group] Failure in periodic indexer worker thread
>>>> 
>>>>  
>>>> 
>>>> Steve, 
>>>> The url you linked would be the same issue, so yes the indexer tries to index the same items over and over...  I'll have to inspect the records to see what is causing the migration to fail.
>>>> 
>>>>  
>>>> 
>>>> On Tue, Mar 14, 2017 at 3:13 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu <mailto:sdm7g at eservices.virginia.edu>> wrote:
>>>> 
>>>>  
>>>> 
>>>> Check for errors in the container conversion batch job log files. 
>>>> 
>>>>  
>>>> 
>>>> Does the indexer appear to keep trying to reindex the same records over and over ? 
>>>> 
>>>>  
>>>> 
>>>> See previous thread: 
>>>> 
>>>> http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2017-January/004370.html>
>>>>  
>>>> 
>>>> ? Steve Majewski
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> On Mar 14, 2017, at 2:45 PM, Hawk, Patrick <hawkpf at miamioh.edu <mailto:hawkpf at miamioh.edu>> wrote:
>>>> 
>>>>  
>>>> 
>>>> Hello,
>>>> 
>>>> I'm trying to upgrade Archivesspace from 1.4.2 to 1.5.3 but I'm having issues getting my content to fully load.  I followed the instructions here:http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/ <http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/>.  I removed the directory /archivesspace/data/indexter_state and /archivesspace/data/solr_index/index as the directions stated I should do when upgrading to 1.5.0.  I also ran the setup-database.sh without issue.
>>>> 
>>>>  
>>>> 
>>>> However, I receive the following error:  Failure in periodic indexer worker thread: {"error":"undefined method `related_records' for nil:NilClass"} in the archivesspace.out file.  At this point the logs suggest that all items have been re-indexed but my content does not fully load.  Any suggestions? 
>>>> 
>>>> _______________________________________________
>>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>>>  
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>>> 
>>>> 
>>>>  
>>>> 
>>>> -- 
>>>> 
>>>> Patrick Hawk
>>>> 
>>>> 
>>>> 
>>>> King Library Systems
>>>> 
>>>> King Library Room  314
>>>> 
>>>> 513-529-6122 <tel:(513)%20529-6122>
>>>> _______________________________________________
>>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Patrick Hawk
>>>> 
>>>> 
>>>> King Library Systems
>>>> 
>>>> King Library Room  314
>>>> 
>>>> 513-529-6122 <tel:(513)%20529-6122>_______________________________________________
>>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>> 
>>> 
>>> _______________________________________________
>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Patrick Hawk
>>> 
>>> 
>>> King Library Systems
>>> 
>>> King Library Room  314
>>> 
>>> 513-529-6122
>>> 
>>> <AS.PNG>_______________________________________________
>>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>> 
>> _______________________________________________
>> 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 <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
> !DSPAM:58dbfcac43573521512206!
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> 
> 
> !DSPAM:58dbfcac43573521512206!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/6e38ec9d/attachment.html>

From lross at uvm.edu  Thu Mar 30 11:47:14 2017
From: lross at uvm.edu (Lyman Ross)
Date: Thu, 30 Mar 2017 15:47:14 +0000
Subject: [Archivesspace_Users_Group] Path issue with Archivesspace and
	reverse proxy
Message-ID: <437df58a4e314b9c8539a5933504f101@uvm.edu>

We recently migrated our Archivist Toolkit database to Archivesspace and have upgraded to 1.5.4. We're hoping to provide access via nginx and reverse proxy. The public interface is mapped to /archivesspace/public/. Everything seems to be working with the exception of component links which are missing the prefix and showing as relative paths off the webroot. I'm hoping this is a simple configuration issue. Does anyone know which configuration variable controls these links?

Lyman Ross
Systems Librarian
University of Vermont Libraries

lross at uvm.edu
(802) 656-4508

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/9b4beeec/attachment.html>

From blake.carver at lyrasis.org  Thu Mar 30 13:04:33 2017
From: blake.carver at lyrasis.org (Blake Carver)
Date: Thu, 30 Mar 2017 17:04:33 +0000
Subject: [Archivesspace_Users_Group] Path issue with Archivesspace
	and	reverse proxy
In-Reply-To: <437df58a4e314b9c8539a5933504f101@uvm.edu>
References: <437df58a4e314b9c8539a5933504f101@uvm.edu>
Message-ID: <DM5PR08MB244259834108B54BC230233A9F340@DM5PR08MB2442.namprd08.prod.outlook.com>

Hi Lyman,
I have that bug reported in here:
https://archivesspace.atlassian.net/browse/AR-1566

I found the same thing that you did, running under a prefix (in your case /archivesspace/public/) causes some path issues. I never did find a fix, but did find that switching to running the site as 2 subdomains worked just fine. 

Blake Carver
   Systems Administrator LYRASIS
   blake.carver at lyrasis.org
 



________________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Lyman Ross <lross at uvm.edu>
Sent: Thursday, March 30, 2017 11:47 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Path issue with Archivesspace and  reverse proxy

We recently migrated our Archivist Toolkit database to Archivesspace and have upgraded to 1.5.4. We?re hoping to provide access via nginx and reverse proxy. The public interface is mapped to /archivesspace/public/. Everything seems to be working with the exception of component links which are missing the prefix and showing as relative paths off the webroot. I?m hoping this is a simple configuration issue. Does anyone know which configuration variable controls these links?

Lyman Ross
Systems Librarian
University of Vermont Libraries

lross at uvm.edu
(802) 656-4508


From livsolis at utexas.edu  Thu Mar 30 14:05:30 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Thu, 30 Mar 2017 13:05:30 -0500
Subject: [Archivesspace_Users_Group] Accruals/related accesions
Message-ID: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>

Hello all,

We at the Briscoe are pretty far along the path to implementing ASpace, but
have a number of unresolved issues. One being we are still figuring out how
to deal with our accessions that are accruals. The Initially, we had
thought to have all accessions in an accrual be related accessions with a
sibling relationship. I ran a test with 3 collections: Collection 1,
Collection 2, and Collection 3. Steps:

1) Link Collection 1 and Collection 2 as related accessions/siblings.
2) Link Collection 1 and Collection 3 as related accessions/siblings.

My assumption was that Collection 2 and Collection 3 would automatically be
related as siblings, but this was not the case. Is this behavior a known
issue or is there some logic behind this? Am I missing something? I would
think that ASpace would consider all the accessions in a daisy-chained
series of siblings as siblings of each other. If this is not the case, the
maintenance in connecting 20 related accessions/sibling records would be
enormous.

Nonetheless this led me to decide it might be better to have the first
accession in the series of accruals be considered the parent and all the
additional accessions be considered related accessions/forms part of the
parent/first accrual. I ran another test:

1) Create Collection 4 and spawn an accession from it, Collection 5.
2) Connect the two as related accessions, with Collection 5 designated a
child of Collection 4.
3) Spawn a resource from Collection 4, and check related accession.

In the spawned resource, only Collection 4 was linked as a related
accession in the newly spawned resource. I would have expected Collection 5
to be linked as a related accession in the resource as well. Again, same
question. Is this a known issue, or is there some logic behind this? We'd
like to indicate all source accessions that are part of the accrual in the
related resource records. It would seem like the related accessions should
automatically funnel in as related accessions in the resource.

How are some of you representing accruals in ArchivesSpace? Have you
encountered any problems with your decisions, and did what was the logic of
why you decided to go the route that you did?

Thanks!!
Olivia

-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/b6b42fd6/attachment.html>

From lross at uvm.edu  Thu Mar 30 15:10:42 2017
From: lross at uvm.edu (Lyman Ross)
Date: Thu, 30 Mar 2017 19:10:42 +0000
Subject: [Archivesspace_Users_Group] Path issue with
	Archivesspace	and	reverse proxy
In-Reply-To: <DM5PR08MB244259834108B54BC230233A9F340@DM5PR08MB2442.namprd08.prod.outlook.com>
References: <437df58a4e314b9c8539a5933504f101@uvm.edu>
 <DM5PR08MB244259834108B54BC230233A9F340@DM5PR08MB2442.namprd08.prod.outlook.com>
Message-ID: <6edf59bf8375435c81e7b0398bda4b64@uvm.edu>

Thanks, Blake. I'll stop trying to get this to work and get a couple of subdomains instead.

-Lyman

-----Original Message-----
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Blake Carver
Sent: Thursday, March 30, 2017 1:05 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: Re: [Archivesspace_Users_Group] Path issue with Archivesspace and reverse proxy

Hi Lyman,
I have that bug reported in here:
https://archivesspace.atlassian.net/browse/AR-1566

I found the same thing that you did, running under a prefix (in your case /archivesspace/public/) causes some path issues. I never did find a fix, but did find that switching to running the site as 2 subdomains worked just fine. 

Blake Carver
   Systems Administrator LYRASIS
   blake.carver at lyrasis.org
 



________________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Lyman Ross <lross at uvm.edu>
Sent: Thursday, March 30, 2017 11:47 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Path issue with Archivesspace and  reverse proxy

We recently migrated our Archivist Toolkit database to Archivesspace and have upgraded to 1.5.4. We're hoping to provide access via nginx and reverse proxy. The public interface is mapped to /archivesspace/public/. Everything seems to be working with the exception of component links which are missing the prefix and showing as relative paths off the webroot. I'm hoping this is a simple configuration issue. Does anyone know which configuration variable controls these links?

Lyman Ross
Systems Librarian
University of Vermont Libraries

lross at uvm.edu
(802) 656-4508

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

From jzarrillo at brooklynhistory.org  Thu Mar 30 15:47:53 2017
From: jzarrillo at brooklynhistory.org (John Zarrillo)
Date: Thu, 30 Mar 2017 19:47:53 +0000
Subject: [Archivesspace_Users_Group] Subject/agent sort order
Message-ID: <BN3PR01MB209722EB63387EE4206AB287BB340@BN3PR01MB2097.prod.exchangelabs.com>

We recently noticed that the subject/agents list are no longer alphabetized in resource records that we migrated from AT. My understanding is that the subject/agents are now arranged in the order they were linked to the record. Is there any way to automate a mass resort of these?

John Zarrillo
Senior Archivist
718-222-4111 x205
jzarrillo at brooklynhistory.org<mailto:jzarrillo at brooklynhistory.org>

[bhs-150-logo-horizontal-rgb.png]<http://www.brooklynhistory.org/>
Twitter<https://twitter.com/brooklynhistory> I Facebook<https://www.facebook.com/BrooklynHistory> I Instagram<http://instagram.com/brooklynhistory>

Quick Links: Visit the Library<http://brooklynhistory.org/library/visit.html> | Search the Collections<http://brooklynhistory.org/library/search.html> | Ask a Q<http://brooklynhistory.org/library/ask.html> | Class Visits<http://brooklynhistory.org/library/request.php> | Image Requests<http://brooklynhistory.org/docs/Collection_Reproduction_Application_Form_2014.pdf> | Donate<http://brooklynhistory.org/library/donation.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/7966869f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21471 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/7966869f/attachment.png>

From mary.caldera at yale.edu  Thu Mar 30 16:31:07 2017
From: mary.caldera at yale.edu (Caldera, Mary)
Date: Thu, 30 Mar 2017 20:31:07 +0000
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
Message-ID: <CY1PR08MB1311FB07395E75CF093AF185E4340@CY1PR08MB1311.namprd08.prod.outlook.com>

Hi, Olivia,
We use represent accruals in AS Resource records and I am happy to discuss our reasoning. I am not sure I understand your scenarios, can you send me screenshots? ? Mary Caldera

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Thursday, March 30, 2017 2:06 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Accruals/related accesions

Hello all,

We at the Briscoe are pretty far along the path to implementing ASpace, but have a number of unresolved issues. One being we are still figuring out how to deal with our accessions that are accruals. The Initially, we had thought to have all accessions in an accrual be related accessions with a sibling relationship. I ran a test with 3 collections: Collection 1, Collection 2, and Collection 3. Steps:

1) Link Collection 1 and Collection 2 as related accessions/siblings.
2) Link Collection 1 and Collection 3 as related accessions/siblings.

My assumption was that Collection 2 and Collection 3 would automatically be related as siblings, but this was not the case. Is this behavior a known issue or is there some logic behind this? Am I missing something? I would think that ASpace would consider all the accessions in a daisy-chained series of siblings as siblings of each other. If this is not the case, the maintenance in connecting 20 related accessions/sibling records would be enormous.

Nonetheless this led me to decide it might be better to have the first accession in the series of accruals be considered the parent and all the additional accessions be considered related accessions/forms part of the parent/first accrual. I ran another test:

1) Create Collection 4 and spawn an accession from it, Collection 5.
2) Connect the two as related accessions, with Collection 5 designated a child of Collection 4.
3) Spawn a resource from Collection 4, and check related accession.

In the spawned resource, only Collection 4 was linked as a related accession in the newly spawned resource. I would have expected Collection 5 to be linked as a related accession in the resource as well. Again, same question. Is this a known issue, or is there some logic behind this? We'd like to indicate all source accessions that are part of the accrual in the related resource records. It would seem like the related accessions should automatically funnel in as related accessions in the resource.

How are some of you representing accruals in ArchivesSpace? Have you encountered any problems with your decisions, and did what was the logic of why you decided to go the route that you did?

Thanks!!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/368520a6/attachment.html>

From livsolis at utexas.edu  Thu Mar 30 17:59:25 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Thu, 30 Mar 2017 16:59:25 -0500
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <CY1PR08MB1311FB07395E75CF093AF185E4340@CY1PR08MB1311.namprd08.prod.outlook.com>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
 <CY1PR08MB1311FB07395E75CF093AF185E4340@CY1PR08MB1311.namprd08.prod.outlook.com>
Message-ID: <CAKu+i=2aBTy4t5ivoY3FwQWjXM=rt3Tb4aQzZaMXS+GKFuQy4A@mail.gmail.com>

Hi Mary,

Sure, and thanks! For accessions, it made sense to us to document accruals
as linked related accessions. We thought about whether to make the link
relationship a sibling or parent/child relationship, but had initially
assumed every accrual would inherit all the familiar links.

The first 8 screen shots illustrate my first test, where the assumption
that all accessions are siblings of one another.
1) Created link from Collection 3 to Collection 1. (Collection 3 being an
accrual to Collection 1)
2) Collection 3 with linked sibling record, Collection 1.
3) Created link from Collection 2 to Collection 1. (Collection 2 also being
an accrual to the same set of collections)
4) Collection 2 with linked sibling record, Collection 1.
5) Collection 1 with two siblings, Collections 2 and 3.
6) Click on link to Collection 3.
7) Collection 3 only has link to Collection 1 even though Collection 2 is
also Collection 1's sibling, and therefore, in my mind, sibling to 3 as
well. (this may be incorrect logic.)
8) Also view Collection 2; same issue as above.

Maintenance seems unsustainable in this scenario as we'd want all accruals
to be linked to one another. We would have to link Collection 2 to
Collection 3 as a sibling. If another accrual to the collection came in, we
would need to individually link it to Collection 1, Collection 2, and
Collection 3 to identify all of its sibling accruals. And so on. Presuming
that Collection 2 and Collection 3 can be siblings of Collection 1 but not
necessarily to each other, a parent child relationship would seem to
establish the appropriate connections. We tested this through the resource,
to see if the resource copied over not only the parent accession, but also
its child. Screen shots 9 through 15 illustrate the 2nd test:

9) Create a Collection 4.
10) Spawn a new accession from Collection 4.
11) Rename spawned accession Collection 5.
12) In Collection 5, scroll down and create Related Accessions link to
Collection 4. (Collection 4 = parent, Collection 5 = child)
13) Return to Collection 4, and spawn resource.
14) Spawned resource from Collection 4.
15) Scroll down to view related accessions. Only Collection 4 appears, not
Collection 4's child/related accession, Collection 5. Shouldn't it appear
in the resource as well? In addition to among accession accruals, we would
like to document the accession numbers of all accruals in the resource
record. It would seem like this could be automated through related
accessions links.

Is this clear? Much obliged!

-Olivia






On Thu, Mar 30, 2017 at 3:31 PM, Caldera, Mary <mary.caldera at yale.edu>
wrote:

> Hi, Olivia,
>
> We use represent accruals in AS Resource records and I am happy to discuss
> our reasoning. I am not sure I understand your scenarios, can you send me
> screenshots? ? Mary Caldera
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia
> S Solis
> *Sent:* Thursday, March 30, 2017 2:06 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Accruals/related accesions
>
>
>
> Hello all,
>
>
>
> We at the Briscoe are pretty far along the path to implementing ASpace,
> but have a number of unresolved issues. One being we are still figuring out
> how to deal with our accessions that are accruals. The Initially, we had
> thought to have all accessions in an accrual be related accessions with a
> sibling relationship. I ran a test with 3 collections: Collection 1,
> Collection 2, and Collection 3. Steps:
>
>
>
> 1) Link Collection 1 and Collection 2 as related accessions/siblings.
>
> 2) Link Collection 1 and Collection 3 as related accessions/siblings.
>
>
>
> My assumption was that Collection 2 and Collection 3 would automatically
> be related as siblings, but this was not the case. Is this behavior a known
> issue or is there some logic behind this? Am I missing something? I would
> think that ASpace would consider all the accessions in a daisy-chained
> series of siblings as siblings of each other. If this is not the case, the
> maintenance in connecting 20 related accessions/sibling records would be
> enormous.
>
>
>
> Nonetheless this led me to decide it might be better to have the first
> accession in the series of accruals be considered the parent and all the
> additional accessions be considered related accessions/forms part of the
> parent/first accrual. I ran another test:
>
>
>
> 1) Create Collection 4 and spawn an accession from it, Collection 5.
>
> 2) Connect the two as related accessions, with Collection 5 designated a
> child of Collection 4.
>
> 3) Spawn a resource from Collection 4, and check related accession.
>
>
>
> In the spawned resource, only Collection 4 was linked as a related
> accession in the newly spawned resource. I would have expected Collection 5
> to be linked as a related accession in the resource as well. Again, same
> question. Is this a known issue, or is there some logic behind this? We'd
> like to indicate all source accessions that are part of the accrual in the
> related resource records. It would seem like the related accessions should
> automatically funnel in as related accessions in the resource.
>
>
>
> How are some of you representing accruals in ArchivesSpace? Have you
> encountered any problems with your decisions, and did what was the logic of
> why you decided to go the route that you did?
>
>
>
> Thanks!!
>
> Olivia
>
>
>
> --
>
> Olivia Solis, MSIS
>
> Metadata Coordinator
>
> Dolph Briscoe Center for American History
>
> The University of Texas at Austin
>
> 2300 Red River St. Stop D1100
>
> Austin TX, 78712-1426
>
> (512) 232-8013 <(512)%20232-8013>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_Link_C3_to_C1.png
Type: image/png
Size: 46222 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2_C3_C1_Linked.png
Type: image/png
Size: 116998 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3_Link_C2_toC1.png
Type: image/png
Size: 48502 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4_C2_C1_linked.png
Type: image/png
Size: 71572 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5_C1_sibling_of_C2_C3.png
Type: image/png
Size: 89329 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0019.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6_view_C3.png
Type: image/png
Size: 100293 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0020.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7_C2_not_sibling.png
Type: image/png
Size: 90799 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0021.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8_C3_not_sibling.png
Type: image/png
Size: 79570 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0022.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9_create_C4.png
Type: image/png
Size: 63984 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0023.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10_spawn_accesion.png
Type: image/png
Size: 39546 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0024.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 11_Create_C5.png
Type: image/png
Size: 49359 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0025.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12_link_C5_as_child_of_C4.png
Type: image/png
Size: 49066 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0026.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13_spawn_resource_from_C4.png
Type: image/png
Size: 32955 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0027.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 14_spawned_resource.png
Type: image/png
Size: 45958 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0028.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15_scroll_to_related_accession.png
Type: image/png
Size: 37430 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170330/27912f61/attachment-0029.png>

From smithkr at mit.edu  Fri Mar 31 09:32:34 2017
From: smithkr at mit.edu (Kari R Smith)
Date: Fri, 31 Mar 2017 13:32:34 +0000
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
Message-ID: <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>

Hi Olivia,
Can you explain more about how you are distinguishing between accessions that are accruals from those that are not?

Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/  @karirene69

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Thursday, March 30, 2017 2:06 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Accruals/related accesions

Hello all,

We at the Briscoe are pretty far along the path to implementing ASpace, but have a number of unresolved issues. One being we are still figuring out how to deal with our accessions that are accruals. The Initially, we had thought to have all accessions in an accrual be related accessions with a sibling relationship. I ran a test with 3 collections: Collection 1, Collection 2, and Collection 3. Steps:

1) Link Collection 1 and Collection 2 as related accessions/siblings.
2) Link Collection 1 and Collection 3 as related accessions/siblings.

My assumption was that Collection 2 and Collection 3 would automatically be related as siblings, but this was not the case. Is this behavior a known issue or is there some logic behind this? Am I missing something? I would think that ASpace would consider all the accessions in a daisy-chained series of siblings as siblings of each other. If this is not the case, the maintenance in connecting 20 related accessions/sibling records would be enormous.

Nonetheless this led me to decide it might be better to have the first accession in the series of accruals be considered the parent and all the additional accessions be considered related accessions/forms part of the parent/first accrual. I ran another test:

1) Create Collection 4 and spawn an accession from it, Collection 5.
2) Connect the two as related accessions, with Collection 5 designated a child of Collection 4.
3) Spawn a resource from Collection 4, and check related accession.

In the spawned resource, only Collection 4 was linked as a related accession in the newly spawned resource. I would have expected Collection 5 to be linked as a related accession in the resource as well. Again, same question. Is this a known issue, or is there some logic behind this? We'd like to indicate all source accessions that are part of the accrual in the related resource records. It would seem like the related accessions should automatically funnel in as related accessions in the resource.

How are some of you representing accruals in ArchivesSpace? Have you encountered any problems with your decisions, and did what was the logic of why you decided to go the route that you did?

Thanks!!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/86a2bab7/attachment.html>

From livsolis at utexas.edu  Fri Mar 31 10:05:46 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Fri, 31 Mar 2017 09:05:46 -0500
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
 <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>
Message-ID: <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>

Hi Kari,

Our registrar determines this, but essentially we consider an accession
that has the same creator and is the same resource type as an existing
collection an accrual. Sometimes this is very obvious. For instance, we are
the university archives (University of Texas) and regularly receive
records/papers from departments and faculty. So if we have already received
an accession from a particular professor, a new accession from him or her
would be an accrual. If a professor sends materials to us for the first
time, the accession is not an accrual, though any subsequent accessions
he/she passes on would be.

Most of the time, whether or not something is an accrual is clear to our
registrar, but sometimes he has to do a little digging to see if an
accession is an addition to an already existing collection.

Does that make sense?

Thanks,
Olivia

On Fri, Mar 31, 2017 at 8:32 AM, Kari R Smith <smithkr at mit.edu> wrote:

> Hi Olivia,
>
> Can you explain more about how you are distinguishing between accessions
> that are accruals from those that are not?
>
>
>
> Kari R. Smith
>
> Digital Archivist and Program Head for Born-digital Archives
>
> Institute Archives and Special Collections
>
> Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
>
> 617.253.5690 <(617)%20253-5690>   smithkr at mit.edu
> http://libraries.mit.edu/archives/  @karirene69
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia
> S Solis
> *Sent:* Thursday, March 30, 2017 2:06 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Accruals/related accesions
>
>
>
> Hello all,
>
>
>
> We at the Briscoe are pretty far along the path to implementing ASpace,
> but have a number of unresolved issues. One being we are still figuring out
> how to deal with our accessions that are accruals. The Initially, we had
> thought to have all accessions in an accrual be related accessions with a
> sibling relationship. I ran a test with 3 collections: Collection 1,
> Collection 2, and Collection 3. Steps:
>
>
>
> 1) Link Collection 1 and Collection 2 as related accessions/siblings.
>
> 2) Link Collection 1 and Collection 3 as related accessions/siblings.
>
>
>
> My assumption was that Collection 2 and Collection 3 would automatically
> be related as siblings, but this was not the case. Is this behavior a known
> issue or is there some logic behind this? Am I missing something? I would
> think that ASpace would consider all the accessions in a daisy-chained
> series of siblings as siblings of each other. If this is not the case, the
> maintenance in connecting 20 related accessions/sibling records would be
> enormous.
>
>
>
> Nonetheless this led me to decide it might be better to have the first
> accession in the series of accruals be considered the parent and all the
> additional accessions be considered related accessions/forms part of the
> parent/first accrual. I ran another test:
>
>
>
> 1) Create Collection 4 and spawn an accession from it, Collection 5.
>
> 2) Connect the two as related accessions, with Collection 5 designated a
> child of Collection 4.
>
> 3) Spawn a resource from Collection 4, and check related accession.
>
>
>
> In the spawned resource, only Collection 4 was linked as a related
> accession in the newly spawned resource. I would have expected Collection 5
> to be linked as a related accession in the resource as well. Again, same
> question. Is this a known issue, or is there some logic behind this? We'd
> like to indicate all source accessions that are part of the accrual in the
> related resource records. It would seem like the related accessions should
> automatically funnel in as related accessions in the resource.
>
>
>
> How are some of you representing accruals in ArchivesSpace? Have you
> encountered any problems with your decisions, and did what was the logic of
> why you decided to go the route that you did?
>
>
>
> Thanks!!
>
> Olivia
>
>
>
> --
>
> Olivia Solis, MSIS
>
> Metadata Coordinator
>
> Dolph Briscoe Center for American History
>
> The University of Texas at Austin
>
> 2300 Red River St. Stop D1100
>
> Austin TX, 78712-1426
>
> (512) 232-8013 <(512)%20232-8013>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/b40fbdef/attachment.html>

From michael_vandermillen at harvard.edu  Fri Mar 31 12:38:46 2017
From: michael_vandermillen at harvard.edu (Vandermillen, Michael)
Date: Fri, 31 Mar 2017 16:38:46 +0000
Subject: [Archivesspace_Users_Group] error upgrading to 2.0
Message-ID: <CY1PR07MB2715B47EF15931926D6D1821E7370@CY1PR07MB2715.namprd07.prod.outlook.com>

Hello all,
Anyone running into the following error when trying to upgrade to 2.0 release candidate?

WARNING: ERROR: initialization failed
org.jruby.rack.RackInitializationException: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Column 'enumeration_id' cannot be null

Thanks-
Michael

Michael Vandermillen
Digital Library Software Engineer
Library Technology Services, Harvard University IT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/b0fbfb95/attachment.html>

From smithkr at mit.edu  Fri Mar 31 12:46:25 2017
From: smithkr at mit.edu (Kari R Smith)
Date: Fri, 31 Mar 2017 16:46:25 +0000
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
 <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>
 <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>
Message-ID: <29F559819ACA9A4FBF208407D4B63ABB010485FFE5@OC11expo28.exchange.mit.edu>

Olivia,
Would it work to create a User Created data field in the Accession Record to note if the Accession is of TYPE= Accural or TYPE = Accession?  That would allow you to run reports on the differences but they would all be related to the Resource record for the overall collection.

One thing we did when we were using ATK was to only refer back to the original Accession record when we needed to make the link between the record with certain data (for example, if there is a signed gift agreement) first accession record and the subsequent ones.  But we didn?t link all subsequent accession records to themselves.

Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/  @karirene69

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Friday, March 31, 2017 10:06 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Accruals/related accesions

Hi Kari,

Our registrar determines this, but essentially we consider an accession that has the same creator and is the same resource type as an existing collection an accrual. Sometimes this is very obvious. For instance, we are the university archives (University of Texas) and regularly receive records/papers from departments and faculty. So if we have already received an accession from a particular professor, a new accession from him or her would be an accrual. If a professor sends materials to us for the first time, the accession is not an accrual, though any subsequent accessions he/she passes on would be.

Most of the time, whether or not something is an accrual is clear to our registrar, but sometimes he has to do a little digging to see if an accession is an addition to an already existing collection.

Does that make sense?

Thanks,
Olivia

On Fri, Mar 31, 2017 at 8:32 AM, Kari R Smith <smithkr at mit.edu<mailto:smithkr at mit.edu>> wrote:
Hi Olivia,
Can you explain more about how you are distinguishing between accessions that are accruals from those that are not?

Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690<tel:(617)%20253-5690>   smithkr at mit.edu<http://mit.edu>   http://libraries.mit.edu/archives/  @karirene69

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis
Sent: Thursday, March 30, 2017 2:06 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Accruals/related accesions

Hello all,

We at the Briscoe are pretty far along the path to implementing ASpace, but have a number of unresolved issues. One being we are still figuring out how to deal with our accessions that are accruals. The Initially, we had thought to have all accessions in an accrual be related accessions with a sibling relationship. I ran a test with 3 collections: Collection 1, Collection 2, and Collection 3. Steps:

1) Link Collection 1 and Collection 2 as related accessions/siblings.
2) Link Collection 1 and Collection 3 as related accessions/siblings.

My assumption was that Collection 2 and Collection 3 would automatically be related as siblings, but this was not the case. Is this behavior a known issue or is there some logic behind this? Am I missing something? I would think that ASpace would consider all the accessions in a daisy-chained series of siblings as siblings of each other. If this is not the case, the maintenance in connecting 20 related accessions/sibling records would be enormous.

Nonetheless this led me to decide it might be better to have the first accession in the series of accruals be considered the parent and all the additional accessions be considered related accessions/forms part of the parent/first accrual. I ran another test:

1) Create Collection 4 and spawn an accession from it, Collection 5.
2) Connect the two as related accessions, with Collection 5 designated a child of Collection 4.
3) Spawn a resource from Collection 4, and check related accession.

In the spawned resource, only Collection 4 was linked as a related accession in the newly spawned resource. I would have expected Collection 5 to be linked as a related accession in the resource as well. Again, same question. Is this a known issue, or is there some logic behind this? We'd like to indicate all source accessions that are part of the accrual in the related resource records. It would seem like the related accessions should automatically funnel in as related accessions in the resource.

How are some of you representing accruals in ArchivesSpace? Have you encountered any problems with your decisions, and did what was the logic of why you decided to go the route that you did?

Thanks!!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013<tel:(512)%20232-8013>

_______________________________________________
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



--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/a13e4df2/attachment.html>

From laney.mcglohon at lyrasis.org  Fri Mar 31 13:27:42 2017
From: laney.mcglohon at lyrasis.org (Laney McGlohon)
Date: Fri, 31 Mar 2017 17:27:42 +0000
Subject: [Archivesspace_Users_Group] error upgrading to 2.0
Message-ID: <FC51A641-D130-418F-AC10-085D5C97F50F@lyrasis.org>

Hey Michael,

Did you perform a database migration?  I would suggest running the setup-database script in the scripts folder.
Let us know if that fixes the problem.

Thanks,
Laney

Laney McGlohon
ArchivesSpace Tech Lead
laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>
800.999.8558 x2927
laneymcglohon Skype



From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of "Vandermillen, Michael" <michael_vandermillen at harvard.edu>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Friday, March 31, 2017 at 12:38 PM
To: "Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org)" <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] error upgrading to 2.0

Hello all,
Anyone running into the following error when trying to upgrade to 2.0 release candidate?

WARNING: ERROR: initialization failed
org.jruby.rack.RackInitializationException: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Column 'enumeration_id' cannot be null

Thanks-
Michael

Michael Vandermillen
Digital Library Software Engineer
Library Technology Services, Harvard University IT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/c7f9869c/attachment.html>

From michael_vandermillen at harvard.edu  Fri Mar 31 13:36:23 2017
From: michael_vandermillen at harvard.edu (Vandermillen, Michael)
Date: Fri, 31 Mar 2017 17:36:23 +0000
Subject: [Archivesspace_Users_Group] error upgrading to 2.0
In-Reply-To: <FC51A641-D130-418F-AC10-085D5C97F50F@lyrasis.org>
References: <FC51A641-D130-418F-AC10-085D5C97F50F@lyrasis.org>
Message-ID: <CY1PR07MB2715D9DB9728D8AA5D23AE0AE7370@CY1PR07MB2715.namprd07.prod.outlook.com>

Yes, sorry I forgot to mention, I did run the db migration. I?m running the whole upgrade from scratch again just as a sanity check.

Michael

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Laney McGlohon
Sent: Friday, March 31, 2017 1:28 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

Hey Michael,

Did you perform a database migration?  I would suggest running the setup-database script in the scripts folder.
Let us know if that fixes the problem.

Thanks,
Laney

Laney McGlohon
ArchivesSpace Tech Lead
laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>
800.999.8558 x2927
laneymcglohon Skype



From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of "Vandermillen, Michael" <michael_vandermillen at harvard.edu<mailto:michael_vandermillen at harvard.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Friday, March 31, 2017 at 12:38 PM
To: "Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>)" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] error upgrading to 2.0

Hello all,
Anyone running into the following error when trying to upgrade to 2.0 release candidate?

WARNING: ERROR: initialization failed
org.jruby.rack.RackInitializationException: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Column 'enumeration_id' cannot be null

Thanks-
Michael

Michael Vandermillen
Digital Library Software Engineer
Library Technology Services, Harvard University IT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/335252d5/attachment.html>

From michael_vandermillen at harvard.edu  Fri Mar 31 13:55:41 2017
From: michael_vandermillen at harvard.edu (Vandermillen, Michael)
Date: Fri, 31 Mar 2017 17:55:41 +0000
Subject: [Archivesspace_Users_Group] error upgrading to 2.0
In-Reply-To: <CY1PR07MB2715D9DB9728D8AA5D23AE0AE7370@CY1PR07MB2715.namprd07.prod.outlook.com>
References: <FC51A641-D130-418F-AC10-085D5C97F50F@lyrasis.org>
 <CY1PR07MB2715D9DB9728D8AA5D23AE0AE7370@CY1PR07MB2715.namprd07.prod.outlook.com>
Message-ID: <CY1PR07MB2715D9E88CC7E5E60F7EA776E7370@CY1PR07MB2715.namprd07.prod.outlook.com>

I?m still getting the same error. I don?t know if there?s something specific to my db; but I did confirm there are no nulls in the enumeration_id column,  enumeration_value table.

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Vandermillen, Michael
Sent: Friday, March 31, 2017 1:36 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

Yes, sorry I forgot to mention, I did run the db migration. I?m running the whole upgrade from scratch again just as a sanity check.

Michael

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Laney McGlohon
Sent: Friday, March 31, 2017 1:28 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

Hey Michael,

Did you perform a database migration?  I would suggest running the setup-database script in the scripts folder.
Let us know if that fixes the problem.

Thanks,
Laney

Laney McGlohon
ArchivesSpace Tech Lead
laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>
800.999.8558 x2927
laneymcglohon Skype



From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of "Vandermillen, Michael" <michael_vandermillen at harvard.edu<mailto:michael_vandermillen at harvard.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Friday, March 31, 2017 at 12:38 PM
To: "Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>)" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] error upgrading to 2.0

Hello all,
Anyone running into the following error when trying to upgrade to 2.0 release candidate?

WARNING: ERROR: initialization failed
org.jruby.rack.RackInitializationException: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Column 'enumeration_id' cannot be null

Thanks-
Michael

Michael Vandermillen
Digital Library Software Engineer
Library Technology Services, Harvard University IT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/93af30e5/attachment.html>

From michael_vandermillen at harvard.edu  Fri Mar 31 14:01:08 2017
From: michael_vandermillen at harvard.edu (Vandermillen, Michael)
Date: Fri, 31 Mar 2017 18:01:08 +0000
Subject: [Archivesspace_Users_Group] error upgrading to 2.0
In-Reply-To: <CY1PR07MB2715D9E88CC7E5E60F7EA776E7370@CY1PR07MB2715.namprd07.prod.outlook.com>
References: <FC51A641-D130-418F-AC10-085D5C97F50F@lyrasis.org>
 <CY1PR07MB2715D9DB9728D8AA5D23AE0AE7370@CY1PR07MB2715.namprd07.prod.outlook.com>
 <CY1PR07MB2715D9E88CC7E5E60F7EA776E7370@CY1PR07MB2715.namprd07.prod.outlook.com>
Message-ID: <CY1PR07MB271510BE25764B192E1B0CAEE7370@CY1PR07MB2715.namprd07.prod.outlook.com>

Aha! Commented out our plugins and no more error; I did notice there was something different about plugin config in the the announcement, so I?ll check that out.

Thanks-

Michael

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Vandermillen, Michael
Sent: Friday, March 31, 2017 1:56 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

I?m still getting the same error. I don?t know if there?s something specific to my db; but I did confirm there are no nulls in the enumeration_id column,  enumeration_value table.

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Vandermillen, Michael
Sent: Friday, March 31, 2017 1:36 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

Yes, sorry I forgot to mention, I did run the db migration. I?m running the whole upgrade from scratch again just as a sanity check.

Michael

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Laney McGlohon
Sent: Friday, March 31, 2017 1:28 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] error upgrading to 2.0

Hey Michael,

Did you perform a database migration?  I would suggest running the setup-database script in the scripts folder.
Let us know if that fixes the problem.

Thanks,
Laney

Laney McGlohon
ArchivesSpace Tech Lead
laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>
800.999.8558 x2927
laneymcglohon Skype



From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of "Vandermillen, Michael" <michael_vandermillen at harvard.edu<mailto:michael_vandermillen at harvard.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Friday, March 31, 2017 at 12:38 PM
To: "Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>)" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] error upgrading to 2.0

Hello all,
Anyone running into the following error when trying to upgrade to 2.0 release candidate?

WARNING: ERROR: initialization failed
org.jruby.rack.RackInitializationException: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Column 'enumeration_id' cannot be null

Thanks-
Michael

Michael Vandermillen
Digital Library Software Engineer
Library Technology Services, Harvard University IT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/bceed7ef/attachment.html>

From livsolis at utexas.edu  Fri Mar 31 18:07:42 2017
From: livsolis at utexas.edu (Olivia S Solis)
Date: Fri, 31 Mar 2017 17:07:42 -0500
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <29F559819ACA9A4FBF208407D4B63ABB010485FFE5@OC11expo28.exchange.mit.edu>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
 <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>
 <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>
 <29F559819ACA9A4FBF208407D4B63ABB010485FFE5@OC11expo28.exchange.mit.edu>
Message-ID: <CAKu+i=1FmB8n1ovAOAFx0Wz94c+wta1rFDseebBcOyweAucXSQ@mail.gmail.com>

Hi Kari,

Thanks for the information! Correct me if I'm wrong, but it sounds like you
do create a related resource link in each accession to connect it to the
appropriate resource record.

There are instances where we want to know, for instance, which accession
were new in a given time period vs. ones that are not and so that is why
having this information would be useful. A user defined field could be a
possibility. When we were initially embarking on this ASpace journey, we
were resistant to user defined fields, but I've grown warmer to the idea.

Thanks again!
Olivia

On Fri, Mar 31, 2017 at 11:46 AM, Kari R Smith <smithkr at mit.edu> wrote:

> Olivia,
>
> Would it work to create a User Created data field in the Accession Record
> to note if the Accession is of TYPE= Accural or TYPE = Accession?  That
> would allow you to run reports on the differences but they would all be
> related to the Resource record for the overall collection.
>
>
>
> One thing we did when we were using ATK was to only refer back to the
> original Accession record when we needed to make the link between the
> record with certain data (for example, if there is a signed gift agreement)
> first accession record and the subsequent ones.  But we didn?t link all
> subsequent accession records to themselves.
>
>
>
> Kari R. Smith
>
> Digital Archivist and Program Head for Born-digital Archives
>
> Institute Archives and Special Collections
>
> Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
>
> 617.253.5690 <(617)%20253-5690>   smithkr at mit.edu
> http://libraries.mit.edu/archives/  @karirene69
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia
> S Solis
> *Sent:* Friday, March 31, 2017 10:06 AM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Accruals/related accesions
>
>
>
> Hi Kari,
>
>
>
> Our registrar determines this, but essentially we consider an accession
> that has the same creator and is the same resource type as an existing
> collection an accrual. Sometimes this is very obvious. For instance, we are
> the university archives (University of Texas) and regularly receive
> records/papers from departments and faculty. So if we have already received
> an accession from a particular professor, a new accession from him or her
> would be an accrual. If a professor sends materials to us for the first
> time, the accession is not an accrual, though any subsequent accessions
> he/she passes on would be.
>
>
>
> Most of the time, whether or not something is an accrual is clear to our
> registrar, but sometimes he has to do a little digging to see if an
> accession is an addition to an already existing collection.
>
>
>
> Does that make sense?
>
>
>
> Thanks,
>
> Olivia
>
>
>
> On Fri, Mar 31, 2017 at 8:32 AM, Kari R Smith <smithkr at mit.edu> wrote:
>
> Hi Olivia,
>
> Can you explain more about how you are distinguishing between accessions
> that are accruals from those that are not?
>
>
>
> Kari R. Smith
>
> Digital Archivist and Program Head for Born-digital Archives
>
> Institute Archives and Special Collections
>
> Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
>
> 617.253.5690 <(617)%20253-5690>   smithkr at mit.edu
> http://libraries.mit.edu/archives/  @karirene69
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia
> S Solis
> *Sent:* Thursday, March 30, 2017 2:06 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Accruals/related accesions
>
>
>
> Hello all,
>
>
>
> We at the Briscoe are pretty far along the path to implementing ASpace,
> but have a number of unresolved issues. One being we are still figuring out
> how to deal with our accessions that are accruals. The Initially, we had
> thought to have all accessions in an accrual be related accessions with a
> sibling relationship. I ran a test with 3 collections: Collection 1,
> Collection 2, and Collection 3. Steps:
>
>
>
> 1) Link Collection 1 and Collection 2 as related accessions/siblings.
>
> 2) Link Collection 1 and Collection 3 as related accessions/siblings.
>
>
>
> My assumption was that Collection 2 and Collection 3 would automatically
> be related as siblings, but this was not the case. Is this behavior a known
> issue or is there some logic behind this? Am I missing something? I would
> think that ASpace would consider all the accessions in a daisy-chained
> series of siblings as siblings of each other. If this is not the case, the
> maintenance in connecting 20 related accessions/sibling records would be
> enormous.
>
>
>
> Nonetheless this led me to decide it might be better to have the first
> accession in the series of accruals be considered the parent and all the
> additional accessions be considered related accessions/forms part of the
> parent/first accrual. I ran another test:
>
>
>
> 1) Create Collection 4 and spawn an accession from it, Collection 5.
>
> 2) Connect the two as related accessions, with Collection 5 designated a
> child of Collection 4.
>
> 3) Spawn a resource from Collection 4, and check related accession.
>
>
>
> In the spawned resource, only Collection 4 was linked as a related
> accession in the newly spawned resource. I would have expected Collection 5
> to be linked as a related accession in the resource as well. Again, same
> question. Is this a known issue, or is there some logic behind this? We'd
> like to indicate all source accessions that are part of the accrual in the
> related resource records. It would seem like the related accessions should
> automatically funnel in as related accessions in the resource.
>
>
>
> How are some of you representing accruals in ArchivesSpace? Have you
> encountered any problems with your decisions, and did what was the logic of
> why you decided to go the route that you did?
>
>
>
> Thanks!!
>
> Olivia
>
>
>
> --
>
> Olivia Solis, MSIS
>
> Metadata Coordinator
>
> Dolph Briscoe Center for American History
>
> The University of Texas at Austin
>
> 2300 Red River St. Stop D1100
>
> Austin TX, 78712-1426
>
> (512) 232-8013 <(512)%20232-8013>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
>
> --
>
> Olivia Solis, MSIS
>
> Metadata Coordinator
>
> Dolph Briscoe Center for American History
>
> The University of Texas at Austin
>
> 2300 Red River St. Stop D1100
>
> Austin TX, 78712-1426
>
> (512) 232-8013 <(512)%20232-8013>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/b0514068/attachment.html>

From rmrichar at Central.UH.EDU  Fri Mar 31 12:00:44 2017
From: rmrichar at Central.UH.EDU (Richardson, Matt)
Date: Fri, 31 Mar 2017 11:00:44 -0500
Subject: [Archivesspace_Users_Group] Accruals/related accesions
In-Reply-To: <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>
References: <CAKu+i=2Q57C4LvBTztFcuW+rWEki_N+URC4bpbfwM+vNo5tH7A@mail.gmail.com>
 <29F559819ACA9A4FBF208407D4B63ABB010485F7DC@OC11expo28.exchange.mit.edu>
 <CAKu+i=1smc2QD8qE3pqCroSgO74-9J6Kkv1yB=AF_BJcN1FWLQ@mail.gmail.com>
Message-ID: <401357DBD992C64D90C44BD7518424852D5C94CF43@EXSERVER5.cougarnet.uh.edu>

Here at UH we are approaching things in a very similar way to what Olivia has described. We?ve been looking for better ways of tracking accruals/additions to existing collections  for a while now, and are still experimenting with how to best implement this in ASpace.

One of our main use-cases is linking new (and therefore unprocessed) additions to existing (processed) collections. This happens a lot with University Archives, but also with a number of external organizations whose records we hold.

We also have related accessions that don?t yet correspond to a processed collection (a Resource Record), or where there are multiple related accruals that are not yet processed into the existing collection. In those instances, we had thought to relate them as siblings, as Olivia described, but noted the same issue in that linkages A-B and B-C don?t transfer to A-C.

I?m attaching a screen shot that illustrates both cases in a single set of accessions (though, notably, the Resource record for the processed collection has not yet be created in ASpace).

We haven?t settled on the best way to move forward with this, and would welcome other thoughts.

Thanks,
Matt

Matt Richardson, Program Manager
Special Collections
University of Houston Libraries
A Carnegie-designated Tier One public research university
713-743-9229
rmrichardson at uh.edu

Web:  info.lib.uh.edu/sc
Blog:  weblogs.lib.uh.edu/speccol<http://weblogs.lib.uh.edu/speccol/>
Facebook:  facebook.com/UHSpecColl<https://www.facebook.com/UHSpecColl>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Friday, March 31, 2017 9:06 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Accruals/related accesions

Hi Kari,

Our registrar determines this, but essentially we consider an accession that has the same creator and is the same resource type as an existing collection an accrual. Sometimes this is very obvious. For instance, we are the university archives (University of Texas) and regularly receive records/papers from departments and faculty. So if we have already received an accession from a particular professor, a new accession from him or her would be an accrual. If a professor sends materials to us for the first time, the accession is not an accrual, though any subsequent accessions he/she passes on would be.

Most of the time, whether or not something is an accrual is clear to our registrar, but sometimes he has to do a little digging to see if an accession is an addition to an already existing collection.

Does that make sense?

Thanks,
Olivia

On Fri, Mar 31, 2017 at 8:32 AM, Kari R Smith <smithkr at mit.edu<mailto:smithkr at mit.edu>> wrote:
Hi Olivia,
Can you explain more about how you are distinguishing between accessions that are accruals from those that are not?

Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690<tel:(617)%20253-5690>   smithkr at mit.edu<http://mit.edu>   http://libraries.mit.edu/archives/  @karirene69

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis
Sent: Thursday, March 30, 2017 2:06 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Accruals/related accesions

Hello all,

We at the Briscoe are pretty far along the path to implementing ASpace, but have a number of unresolved issues. One being we are still figuring out how to deal with our accessions that are accruals. The Initially, we had thought to have all accessions in an accrual be related accessions with a sibling relationship. I ran a test with 3 collections: Collection 1, Collection 2, and Collection 3. Steps:

1) Link Collection 1 and Collection 2 as related accessions/siblings.
2) Link Collection 1 and Collection 3 as related accessions/siblings.

My assumption was that Collection 2 and Collection 3 would automatically be related as siblings, but this was not the case. Is this behavior a known issue or is there some logic behind this? Am I missing something? I would think that ASpace would consider all the accessions in a daisy-chained series of siblings as siblings of each other. If this is not the case, the maintenance in connecting 20 related accessions/sibling records would be enormous.

Nonetheless this led me to decide it might be better to have the first accession in the series of accruals be considered the parent and all the additional accessions be considered related accessions/forms part of the parent/first accrual. I ran another test:

1) Create Collection 4 and spawn an accession from it, Collection 5.
2) Connect the two as related accessions, with Collection 5 designated a child of Collection 4.
3) Spawn a resource from Collection 4, and check related accession.

In the spawned resource, only Collection 4 was linked as a related accession in the newly spawned resource. I would have expected Collection 5 to be linked as a related accession in the resource as well. Again, same question. Is this a known issue, or is there some logic behind this? We'd like to indicate all source accessions that are part of the accrual in the related resource records. It would seem like the related accessions should automatically funnel in as related accessions in the resource.

How are some of you representing accruals in ArchivesSpace? Have you encountered any problems with your decisions, and did what was the logic of why you decided to go the route that you did?

Thanks!!
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013<tel:(512)%20232-8013>

_______________________________________________
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



--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/4ff00e51/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Linked Accessions.png
Type: image/png
Size: 66008 bytes
Desc: Linked Accessions.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170331/4ff00e51/attachment.png>