From christine.dibella at lyrasis.org Tue Jan 3 09:34:05 2017 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Tue, 3 Jan 2017 14:34:05 +0000 Subject: [Archivesspace_Users_Group] Issues Importing/Rearranging Large Collection Message-ID: Hi Alex, Thanks for bringing this to our attention. As many people are getting back to work this week, you may see some responses on the list. I?m also going to separately open up a tech support ticket and ask our tech folks to investigate. (You?ll see a separate message directly to you from me about this in a little bit.) Christine Christine Di Bella ArchivesSpace Community Outreach Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Alexander Duryee Sent: Wednesday, December 28, 2016 4:02 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Issues Importing/Rearranging Large Collection We were able to successfully import a large collection (~2000 components) into ArchivesSpace, and imported a set of additions to the collection as well. However, after importing the additions, we ran into two problems: 1) After importing the additions via the API, many of the archival objects also have additional "ghost" records in the tree view. These records are just pointers to the "real" object - clicking them opens the correct object - but they cannot be moved/deleted from the collection. In addition, these records are exporting in the EAD XML output (as copies of the "real" record). Most perplexingly, these ghost records don't appear as archival objects in the backend database - only via the frontend and exports. 2) When rearranging archival objects within the collection (via the tree view), the object first appears in the proper location. However, when refreshing the collection, the component appears 5-10 objects away from where it was dropped. This is reinforced by the object's position value in the database - for example, drag-and-dropping an object to position 205 will save it at position 198 instead. Any ideas as to causes/solutions/workarounds would be tremendously appreciated. Many thanks! --Alex -- Alexander Duryee Metadata Archivist New York Public Library (917)-229-9590 alexanderduryee at nypl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From NHOSBURGH at Rollins.edu Tue Jan 3 13:28:06 2017 From: NHOSBURGH at Rollins.edu (Nathan Hosburgh) Date: Tue, 3 Jan 2017 18:28:06 +0000 Subject: [Archivesspace_Users_Group] example custom footer.html Message-ID: Hi, I?m looking for someone who has a customized public footer.html file who is willing to share it so that I can compare with ours. Either the file or simply pasting the text in an email will work. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu (407) 691-1157 http://rollins.academia.edu/NathanHosburgh ?If you would tell me the heart of a man, tell me not what he reads, but what he rereads.? ? Fran?ois Mauriac -------------- next part -------------- An HTML attachment was scrubbed... URL: From faithc at princeton.edu Wed Jan 4 13:37:30 2017 From: faithc at princeton.edu (Faith F. Charlton) Date: Wed, 4 Jan 2017 18:37:30 +0000 Subject: [Archivesspace_Users_Group] user_defined_in_basic plugin issue Message-ID: <5B4168BCF846AD4CB0575C5BFE70FB3853838ECB@csgmbx209w.pu.win.princeton.edu> Hello- I was wondering if anyone else was running into an issue we've encountered with this plugin that we recently added (we're using v1.5.1). For some reason, the plugin is moving the External Documents subrecord Location field into the Basic Information subrecord. I'm not sure if this has something to do with the fact that we also have a "Location" user-defined field; though I don't know why the plugin would be looking at subrecords other than User Defined? Thanks! Faith _______________________________ Faith Charlton Lead Processing Archivist, Manuscript Division Collections Princeton University Library One Washington Road Princeton, NJ 08540 609-258-3223 faithc at princeton.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at hudmol.com Wed Jan 4 19:09:56 2017 From: james at hudmol.com (James Bullen) Date: Thu, 5 Jan 2017 11:09:56 +1100 Subject: [Archivesspace_Users_Group] user_defined_in_basic plugin issue In-Reply-To: <5B4168BCF846AD4CB0575C5BFE70FB3853838ECB@csgmbx209w.pu.win.princeton.edu> References: <5B4168BCF846AD4CB0575C5BFE70FB3853838ECB@csgmbx209w.pu.win.princeton.edu> Message-ID: <6891266F-E902-4A57-8828-84EF1FED59D5@hudmol.com> Hi Faith, Yes, as you guessed, the plugin uses the labels to find the fields to move, so a work around would be to change the label on the user defined field to something other than ?Location?. Cheers, James > On Jan 5, 2017, at 5:37 AM, Faith F. Charlton wrote: > > Hello- > > I was wondering if anyone else was running into an issue we?ve encountered with this plugin that we recently added (we?re using v1.5.1). For some reason, the plugin is moving the External Documents subrecord Location field into the Basic Information subrecord. I?m not sure if this has something to do with the fact that we also have a ?Location? user-defined field; though I don?t know why the plugin would be looking at subrecords other than User Defined? > > Thanks! > Faith > _______________________________ > Faith Charlton > Lead Processing Archivist, Manuscript Division Collections > Princeton University Library > One Washington Road > Princeton, NJ 08540 > 609-258-3223 > faithc at princeton.edu > > !DSPAM:586d40fa99312542811966! _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:586d40fa99312542811966! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandra at wayne.edu Thu Jan 5 15:20:17 2017 From: alexandra at wayne.edu (Alexandra Orchard) Date: Thu, 5 Jan 2017 20:20:17 +0000 Subject: [Archivesspace_Users_Group] Background Jobs Not Running Message-ID: Hi Everyone, We upgraded to 1.5.2 yesterday and now background jobs do not work. I tried importing data (EAD), print to PDF, and running a report (which did create a report after I cancelled it after running for about 3 hours). Importing and printing to PDF were not successful after canceling. I think this may be related/same issue to the "Background jobs piling up in queue," from December except we can't get any background jobs to run. Any ideas/help appreciated! Thanks, -Alexandra Alexandra A. A. Orchard, CA Technical + Metadata Archivist Walter P. Reuther Library of Labor and Urban Affairs Wayne State University 313.577.2658 Copied emails from the "Background Jobs Piling up in Queue" thread from December: We are having the same issue at Michigan State but not with all of the pdfs. Leslie M. Behm ( DB 6) Special Projects Librarian Special Collections, Michigan State University Libraries 366 W. Circle Dr. East Lansing, MI 48824 behm at msu.edu> 517-884-0851 Alt: 517- 884-6471 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jessica Steytler Sent: Monday, December 19, 2016 12:34 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Background jobs piling up in the queue This email constitutes a "me too" on can't print to PDF all of a sudden when I could before. Definitely interested in following what's the possible outcome. We have a hosted instance, so if there's something we ought do, it's going to be asking Lyrasis for help. Jessica Congregational Library & Archives ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org> >> on behalf of Rider, Jacqueline >> Sent: Friday, December 16, 2016 2:02:53 PM To: archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Background jobs piling up in the queue We are using 1.5.1 and are experiencing a pileup in the background jobs queue. This is a first. It started with trying to print a resources instances list. Now we are unable to print to pdf, even finding aids that were printable in the past. IT upped the server capacity to 6GB RAM and 4 CPU cores and wondered if there's something wrong with the report or the data the report generation is trying to use. We have been test-importing into ArchivesSpace legacy XML EAD finding aids created with a locally designed template in Oxygen. Now that's not possible either. I found the Aug-Sept 2015 discussion and shared it with IT. Are these issues present in v. 1.5.1? Can anyone offer any guidance? Thanks, Jackie Rider Jacqueline Rider Digital Archivist Princeton Theological Seminary Library PO Box 821 Princeton NJ 08542 609-497-7862 jacqueline.rider at ptsem.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandra at wayne.edu Thu Jan 5 15:56:28 2017 From: alexandra at wayne.edu (Alexandra Orchard) Date: Thu, 5 Jan 2017 20:56:28 +0000 Subject: [Archivesspace_Users_Group] Background Jobs Not Running In-Reply-To: References: Message-ID: We've solved our issue. (yay!) We suspect that running the ResourcesInancesListReport caused our problem. I checked with my colleague who ran the report, and she was able to successfully run a different report earlier today. When another colleague began digging into our environment, he found mySQL running at 100% capacity. Killing that process solved the issue, and background jobs are running normally again. I hope this helps someone else. Thanks, Alexandra ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Alexandra Orchard Sent: Thursday, January 5, 2017 3:20 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Background Jobs Not Running Hi Everyone, We upgraded to 1.5.2 yesterday and now background jobs do not work. I tried importing data (EAD), print to PDF, and running a report (which did create a report after I cancelled it after running for about 3 hours). Importing and printing to PDF were not successful after canceling. I think this may be related/same issue to the "Background jobs piling up in queue," from December except we can't get any background jobs to run. Any ideas/help appreciated! Thanks, -Alexandra Alexandra A. A. Orchard, CA Technical + Metadata Archivist Walter P. Reuther Library of Labor and Urban Affairs Wayne State University 313.577.2658 Copied emails from the "Background Jobs Piling up in Queue" thread from December: We are having the same issue at Michigan State but not with all of the pdfs. Leslie M. Behm ( DB 6) Special Projects Librarian Special Collections, Michigan State University Libraries 366 W. Circle Dr. East Lansing, MI 48824 behm at msu.edu> 517-884-0851 Alt: 517- 884-6471 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jessica Steytler Sent: Monday, December 19, 2016 12:34 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Background jobs piling up in the queue This email constitutes a "me too" on can't print to PDF all of a sudden when I could before. Definitely interested in following what's the possible outcome. We have a hosted instance, so if there's something we ought do, it's going to be asking Lyrasis for help. Jessica Congregational Library & Archives ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org> >> on behalf of Rider, Jacqueline >> Sent: Friday, December 16, 2016 2:02:53 PM To: archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Background jobs piling up in the queue We are using 1.5.1 and are experiencing a pileup in the background jobs queue. This is a first. It started with trying to print a resources instances list. Now we are unable to print to pdf, even finding aids that were printable in the past. IT upped the server capacity to 6GB RAM and 4 CPU cores and wondered if there's something wrong with the report or the data the report generation is trying to use. We have been test-importing into ArchivesSpace legacy XML EAD finding aids created with a locally designed template in Oxygen. Now that's not possible either. I found the Aug-Sept 2015 discussion and shared it with IT. Are these issues present in v. 1.5.1? Can anyone offer any guidance? Thanks, Jackie Rider Jacqueline Rider Digital Archivist Princeton Theological Seminary Library PO Box 821 Princeton NJ 08542 609-497-7862 jacqueline.rider at ptsem.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From faithc at Princeton.EDU Thu Jan 5 16:47:47 2017 From: faithc at Princeton.EDU (Faith F. Charlton) Date: Thu, 5 Jan 2017 21:47:47 +0000 Subject: [Archivesspace_Users_Group] user_defined_in_basic plugin issue In-Reply-To: <6891266F-E902-4A57-8828-84EF1FED59D5@hudmol.com> References: <5B4168BCF846AD4CB0575C5BFE70FB3853838ECB@csgmbx209w.pu.win.princeton.edu> <6891266F-E902-4A57-8828-84EF1FED59D5@hudmol.com> Message-ID: <5B4168BCF846AD4CB0575C5BFE70FB3853839DD5@csgmbx209w.pu.win.princeton.edu> Ahh, ok. Thanks, James! Best, Faith From: 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 04, 2017 7:10 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] user_defined_in_basic plugin issue Hi Faith, Yes, as you guessed, the plugin uses the labels to find the fields to move, so a work around would be to change the label on the user defined field to something other than ?Location?. Cheers, James On Jan 5, 2017, at 5:37 AM, Faith F. Charlton > wrote: Hello- I was wondering if anyone else was running into an issue we?ve encountered with this plugin that we recently added (we?re using v1.5.1). For some reason, the plugin is moving the External Documents subrecord Location field into the Basic Information subrecord. I?m not sure if this has something to do with the fact that we also have a ?Location? user-defined field; though I don?t know why the plugin would be looking at subrecords other than User Defined? Thanks! Faith _______________________________ Faith Charlton Lead Processing Archivist, Manuscript Division Collections Princeton University Library One Washington Road Princeton, NJ 08540 609-258-3223 faithc at princeton.edu !DSPAM:586d40fa99312542811966! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:586d40fa99312542811966! -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Fri Jan 6 13:19:30 2017 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Fri, 6 Jan 2017 18:19:30 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Update - January 2017 Message-ID: [ArchivesSpace by LYRASIS] January 2017 Update Development The ArchivesSpace team was pleased to release version 1.5.2 on December 8. You can download the new release from Github at https://github.com/archivesspace/archivesspace/releases/tag/v1.5.2. Please see the release page for a listing of all the new features and bug fixes included in this release. Please see the technical documentation for information on how to upgrade your ArchivesSpace installations. This minor release includes bug fixes and performance improvements, and addresses some minor layout issues in the staff interface. This release includes development work completed by our development partner Hudson Molonglo (HM) as well as pull requests submitted by members of the community including Luis Martinez-Uribe, Alex Duryee, Dave Mayo, Chris Fitzpatrick, and Byron Roosa (apologies to anyone we missed in this list). We want to thank these contributors and all those who participated in testing and provided feedback that fed into these improvements! Let us know if you have questions or encounter problems executing the upgrade. In addition to all the work that went into the 1.5.2 release, HM has been working with a small group to prepare an initial Technology and Development roadmap and performing analysis for upcoming refactor and repair work. The next major release of ArchivesSpace will be in March 2017. Release Webinar We are working on rescheduling the 1.5.2 release webinar that needed to be postponed due to a staff member's unexpected family health issues. More information on the new date and time will be available soon. For those who can't attend at the scheduled time, the webinar will be recorded and available on our website afterwards. Staffing News ArchivesSpace is thrilled that Laney McGlohon will be joining ArchivesSpace as the Technical Lead. Laney is an information scientist, software developer, librarian, and self-described data wrangler with seven years of experience working with special collections and institutional archivists. She has strong programming skills, experience with archival software including ArchivesSpace and a strong interest in outreach to the developer community. Her experience working with archives and understanding of archival practices and data standards along with her extensive software development background will enable her to step into the ArchivesSpace Tech Lead role and hit the ground running. Laney will be responsible for overall development of the software, management of a community-based code contribution process, and will work with the community to engage a broader set of developers to participate in the project, providing technical guidance, support and leadership to create a robust developer community. Laney will serve as the primary contact with our development partner Hudson Molonglo (HM). Most recently, Laney served as the Discovery and Access Engineer at Stanford University Libraries. Before that she served as a Software Engineer at the Getty Research Institute and as Technology Consultant at the Museum of Ventura County. She has also worked at the University of Georgia and Raytheon Systems Corporation. Laney earned a Bachelor's of Science in Mathematical Sciences from University of North Carolina, Chapel Hill, a Master's of Science in Applied Mathematics from North Carolina State University and her Master's in Library Science from University of North Carolina, Chapel Hill. Laney will officially join the ArchivesSpace team January 23rd. Updates on the Public User Interface Enhancement project The Public Interface development group recently provided an updated timeline and additional information on the progress toward the release of the new ArchivesSpace Public User Interface. From Mark Custer, on behalf of the group: "As many of you are aware, we have been aiming to have a candidate release ready for December 16th, with the official, production-ready release to follow in March 2017. However, we are behind schedule at this point, so we have decided to push back the candidate release date until the end of March 2017 to coincide with the next major release of ArchivesSpace. Because of that, we don't expect the production-ready release to be available until June 2017. Even though we are three months behind our original schedule, a LOT of important progress has been made since August, including the following: * We have conducted and outsourced some really important and helpful usability and accessibility tests (thanks to many people at Harvard, Melissa Wisner at Yale, and WebAIM) * Search results have been enhanced, which now include additional description and context (e.g. repository, collection, etc.) * Searches can be limited by date ranges * Searches can be limited to a specific collection / resource record * Sorting options have been added, including the new ability to sort by the year of the described material. * Pagination features have been updated. * The new citation feature has been implemented, which will even work if you have JavaScript turned off * Mixed content and formatted elements display as expected (e.g. italics and bold text is supported, although we're still working out a way to support internal linking features). Essentially what this means is that EAD tags won't display in the PUI! * A robust implementation of archival inheritance has been developed (see AR-1300), which is especially important since the ArchivesSpace PUI provides component-level result pages. If you're interested to learn more about the new inheritance feature, here's a 10-minute screencast that illustrates how it works: https://vimeo.com/195457286 So what features remain to be implemented? There are some minor adjustments, such as: * Ensuring that all unpublished records do not display in the PUI. The ability to unpublish an entire repository and all of the material descriptions attached to that repository will be a new feature in the staff interface, by the way, which will coincide with the release of the new PUI. All repositories will be published by default, as usual, but you will now have the ability to suppress one or more from the PUI if need be, as requested in AR-1228. There are also a few major features yet to be added or completed. Here is a full list of those major features that we're still aiming to include in the candidate release: * Make comprehensive styling updates that will address aesthetic elements of the site as well as make the site even more user-friendly (e.g. not showing every facet on the right-hand side of the page immediately) * Add a single-scroll view of an entire resource record (i.e. the ability to review an resource record and all of its descendants without having to go to separate web pages for each resource component) * Add a container-only view of any resource record that has containers attached, which will users to "peek" inside each box to see the titles of the contents contained within each (taking advantage of the new top container model); or, barring that feature, we'll look at adding an Excel/CSV export option for that same type of flattened view. * Add the Request feature, which will generate an email with the information outlined in AR-1064 * Finish up the Classification / Record Group views * Provide instructions on what can be modified easily and how, along with all necessary updates to the user manual * Update the "Collection organization" side panel so that it will include more links beyond just the links to any immediate children (as per the Cherry Hill design) * Conduct a final pass on the default labels used throughout the application. These labels are really tough, sometimes, depending on the data that follows. Of course, all of the labels in the PUI can be edited within an ArchivesSpace installation. * Add the PDF request feature * Provide a better user interface for those cases when a published digital object record is linked to a published resource, resource component, and/or accession record. * Update the metadata that is embedded in each HTML page to help optimize how search engines understand the ArchivesSpace PUI. * Time permitting, add the book bag feature (although this will likely be postponed) As always, you can see the current state of the new PUI in our test corpus site at: http://pui.hudmol.com (Thanks, again, to Hudson Molonglo for hosting this website!) You can also read the minutes of our development calls, at the following location on the ArchivesSpace wiki: https://archivesspace.atlassian.net/wiki/display/ADC/Meeting+Schedule%2C+Minutes Once the candidate release is available, we will be seeking more feedback via an online survey, and we would especially appreciate all of the institutions who use the current public interface to weigh in heavily at that time. And for those of who have already provided feedback, either directly to me (mark.custer at yale.edu) or by any other means, thank you. It's really been appreciated!" Membership Update Our new members since December 1 include: * Hong Kong Baptist University * Kennesaw State University (Georgia) * Rhode Island State Police Museum Foundation * University of Texas at Austin As of January 6, we have 313 General members, 11 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 for more information. New Training Option The ArchivesSpace Governance Board recently approved a new option for ArchivesSpace training. We are developing a new one-day Basics workshop that will be offered to hosts at a lower cost than our standard training offerings and open to participants regardless of ArchivesSpace membership status. We're particularly interested in working with local and regional archives groups as hosts and we welcome working within the financial constraints of these groups to make this kind of training as economical as possible. Please get in touch with Christine Di Bella (christine.dibella at lyrasis.org) if you or a group you know of would be interested in sponsoring such a workshop. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 5620 bytes Desc: image003.jpg URL: From KennedyN at si.edu Mon Jan 9 15:37:08 2017 From: KennedyN at si.edu (Kennedy, Nancy) Date: Mon, 9 Jan 2017 20:37:08 +0000 Subject: [Archivesspace_Users_Group] Resource ID uniqueness Message-ID: <4142170736420940ACB07EE9EECDC21F34D6E09C@si-msedag04.US.SINET.SI.EDU> Hello all, Is this a bug? While testing EAD import workflows, I noticed that our installation doesn't force uniqueness between: - "1.2.3.4" (all in one id field) - "1-2-3-4" (all in one id field) - "1" "2" "3" "4" (broken out across all 4 id fields) - etc.... many variations are possible Since I expect users will be importing either marc or ead data, I'd like to make sure they can't create "1.2.3.4" or "1-2-3-4" via EAD import, if "1" "2" "3" "4" version already exists. This might be less likely to happen with manual record creation, but it looks like a user could inadvertently duplicate an id that way too. [cid:image001.png at 01D26A8E.3CF7AA90] Thanks, Nancy Nancy Kennedy EAD Coordinator Smithsonian Institution kennedyn at si.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 77391 bytes Desc: image001.png URL: From flemingj at uncw.edu Tue Jan 10 13:38:53 2017 From: flemingj at uncw.edu (Fleming, Jason) Date: Tue, 10 Jan 2017 18:38:53 +0000 Subject: [Archivesspace_Users_Group] Error message when saving record Message-ID: We recently upgraded to 1.5.2 and we came across this error after saving a modification to the title of one of our archival objects translation missing: en.no key - translation missing: en.validation_errors.database_integrity_constraint_conflict__java__commysqljdbcexceptionsjdbc4__mysqlintegrityconstraintviolationexception__duplicate_entry__12276 at archival_object-0__for_key__uniq_ao_pos_ I looked through the listserv and the closest thing I could find seemed to be a bug fixed several versions back in 2014 Has anyone seen something similar or have any suggestions of where to look to fix this problem? I have already tried rebooting the server but that didn't change anything -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fortney at okstate.edu Tue Jan 10 15:25:57 2017 From: kyle.fortney at okstate.edu (Fortney, Kyle) Date: Tue, 10 Jan 2017 20:25:57 +0000 Subject: [Archivesspace_Users_Group] Error message when saving record In-Reply-To: References: Message-ID: We have recently worked through this problem on our 1.4.2 production server and our 1.5.1 test server. It more than likely means that the parent child sequence does not exist in your sequence table. I'm sorry if my grammar is a little confusing (this was tough to figure out), but the following is what we experienced on our servers - The error message is misleading. The uniq_ao_position is a combined index of the parent_name and position fields. The real issue lies with the sequence table. The sequence for a specific parent child grouping or relationship doesn't exist or the value of the sequence is less than the number of child objects within that parent. When a record is saved it checks against the sequence table. If a sequence for a parent child grouping exists it checks the value of that sequence. If you have one child object the value would be 0 (because an index starts at 0) and if you have five child objects the value would be 4. When saving a record where the sequence value is too low it will return an error similar to below with the current sequence value where you see 0 below. To solve this issue, set your sequence value higher than the highest child position WITHIN your specific parent child grouping. What was recommended to us to fix this issue was: "Recommend database backup. Develop query to (re)set appropriate sequence values (or just set all sequence values arbitrarily high -- WARN, TEST THIS and review related code!)." SELECT max(position) FROM archival_object; # 416 UPDATE sequence SET value = 417; # set all sequence values > than highest possible position to satisfy invariant # not presently aware of a downside to this but BEWARE and TEST thoroughly The bigger issue is when the sequence for a parent child grouping doesn't exist. These are harder to find and we have been doing them on a case by case basis. When you see the error message below and have done the above, there are a few ways to do this; Lyrasis highly recommends using the API (no idea how to do this), you can manually create the sequence in the SQL instance, OR the most common and straightforward way, which is to save the first child within a parent child grouping creating the sequence automatically. In any of those instances the newly created sequence will have a value of 0, so if you have more than one child object already present you will need to update the sequence value for the parent child grouping to at least the number of present children objects. I hope this helps. Thanks, Kyle Fortney Computer Specialist Library Systems 308 Edmon Low Library, OSU (405) 744-7924 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fleming, Jason Sent: Tuesday, January 10, 2017 12:39 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Error message when saving record We recently upgraded to 1.5.2 and we came across this error after saving a modification to the title of one of our archival objects translation missing: en.no key - translation missing: en.validation_errors.database_integrity_constraint_conflict__java__commysqljdbcexceptionsjdbc4__mysqlintegrityconstraintviolationexception__duplicate_entry__12276 at archival_object-0__for_key__uniq_ao_pos_ I looked through the listserv and the closest thing I could find seemed to be a bug fixed several versions back in 2014 Has anyone seen something similar or have any suggestions of where to look to fix this problem? I have already tried rebooting the server but that didn't change anything -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From flemingj at uncw.edu Wed Jan 11 09:08:52 2017 From: flemingj at uncw.edu (Fleming, Jason) Date: Wed, 11 Jan 2017 14:08:52 +0000 Subject: [Archivesspace_Users_Group] Error message when saving record In-Reply-To: References: Message-ID: Kyle, Thank you for background on the problem. It looks like you have been dealing with this quite a bit! We resequenced the database using config.rb (Thanks! Noah H.) and that seems to be working so far. If the problem crops up in other places I will definitely looking at everything in more detail. -Jason From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fortney, Kyle Sent: Tuesday, January 10, 2017 3:26 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Error message when saving record We have recently worked through this problem on our 1.4.2 production server and our 1.5.1 test server. It more than likely means that the parent child sequence does not exist in your sequence table. I'm sorry if my grammar is a little confusing (this was tough to figure out), but the following is what we experienced on our servers - The error message is misleading. The uniq_ao_position is a combined index of the parent_name and position fields. The real issue lies with the sequence table. The sequence for a specific parent child grouping or relationship doesn't exist or the value of the sequence is less than the number of child objects within that parent. When a record is saved it checks against the sequence table. If a sequence for a parent child grouping exists it checks the value of that sequence. If you have one child object the value would be 0 (because an index starts at 0) and if you have five child objects the value would be 4. When saving a record where the sequence value is too low it will return an error similar to below with the current sequence value where you see 0 below. To solve this issue, set your sequence value higher than the highest child position WITHIN your specific parent child grouping. What was recommended to us to fix this issue was: "Recommend database backup. Develop query to (re)set appropriate sequence values (or just set all sequence values arbitrarily high -- WARN, TEST THIS and review related code!)." SELECT max(position) FROM archival_object; # 416 UPDATE sequence SET value = 417; # set all sequence values > than highest possible position to satisfy invariant # not presently aware of a downside to this but BEWARE and TEST thoroughly The bigger issue is when the sequence for a parent child grouping doesn't exist. These are harder to find and we have been doing them on a case by case basis. When you see the error message below and have done the above, there are a few ways to do this; Lyrasis highly recommends using the API (no idea how to do this), you can manually create the sequence in the SQL instance, OR the most common and straightforward way, which is to save the first child within a parent child grouping creating the sequence automatically. In any of those instances the newly created sequence will have a value of 0, so if you have more than one child object already present you will need to update the sequence value for the parent child grouping to at least the number of present children objects. I hope this helps. Thanks, Kyle Fortney Computer Specialist Library Systems 308 Edmon Low Library, OSU (405) 744-7924 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fleming, Jason Sent: Tuesday, January 10, 2017 12:39 PM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] Error message when saving record We recently upgraded to 1.5.2 and we came across this error after saving a modification to the title of one of our archival objects translation missing: en.no key - translation missing: en.validation_errors.database_integrity_constraint_conflict__java__commysqljdbcexceptionsjdbc4__mysqlintegrityconstraintviolationexception__duplicate_entry__12276 at archival_object-0__for_key__uniq_ao_pos_ I looked through the listserv and the closest thing I could find seemed to be a bug fixed several versions back in 2014 Has anyone seen something similar or have any suggestions of where to look to fix this problem? I have already tried rebooting the server but that didn't change anything -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From moconway at umich.edu Wed Jan 11 09:24:07 2017 From: moconway at umich.edu (Martha O'Hara Conway) Date: Wed, 11 Jan 2017 09:24:07 -0500 Subject: [Archivesspace_Users_Group] Invitation to Comment: Proposed Level 1 Guidelines for Standardized Holdings Counts and Measures Message-ID: Colleagues -- The SAA-ACRL/RBMS Joint Task Force on the Development of Standardized Holdings Counts and Measures for Archival Repositories and Special Collections Libraries is pleased to invite comments on its proposed ?Level 1 Count? for quantifying and sharing information about the holdings of archival repositories and special collections libraries. Comments are due on or before Friday, 3 March 2017. The document is available online and as a .pdf on this SAA website: Proposed Level 1 Guidelines for Standardized Holdings Counts and Measures Comments should be directed to either or both of the Task Force co-chairs: Martha O?Hara Conway moconway at umich.edu (for RBMS) Emily R. Novak Gustainis emily_gustainis at hms.harvard.edu (for SAA) You do not need to be a member of RBMS or SAA to comment on the proposed ?Level 1 Count.? Thank you in advance for your interest and input! -- Martha, on behalf of the SAA-ACRL/RBMS Joint Task Force on the Development of Standardized Holdings Counts and Measures for Archival Repositories and Special Collections Libraries Martha O?Hara Conway (RBMS) University of Michigan Adriana P. Cuervo (SAA) Rutgers University Rachel A. D'Agostino (RBMS) Library Company of Philadelphia Lara Friedman?Shedlov (RBMS) University of Minnesota Angela Fritz (SAA) University of Arkansas Emily R. Novak Gustainis (SAA) Harvard Medical School E. Haven Hawley (RBMS) University of Florida Lisa K. Miller (SAA) Stanford University Katy E. Rawdon (RBMS) Temple University Cyndi Shein (SAA) University of Nevada ************************************************** Martha O'Hara Conway Director * Special Collections Library University of Michigan * Ann Arbor MI 48109 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alston.Cobourn at tamucc.edu Wed Jan 11 11:15:44 2017 From: Alston.Cobourn at tamucc.edu (Cobourn, Alston) Date: Wed, 11 Jan 2017 16:15:44 +0000 Subject: [Archivesspace_Users_Group] AS upgrade advice needed Message-ID: Dear all, I'm hoping some one can give me upgrade advice. We are currently using AS 1.4.2. Would it be best to upgrade straight from 1.4.2 to 1.5.2 or would it be best to upgrade incrementally? Relatedly, I'd like to do the upgrade first on a test server to make sure the shift in the underlying data model doesn't cause a huge problem for our data. We do not however currently have a test instance. Could I request IT set up a 1.5.2 test instance and import our data straight into that to answer this question or do I really need to have them set up a 1.4.2 test instance, import our data into that, and then upgrade that to 1.5.2. Thank you! Sincerely, Alston Cobourn Processing and Digital Assets Archivist Texas A&M-Corpus Christi 361-852-2300 alston.cobourn at tamucc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Wed Jan 11 11:37:43 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 11 Jan 2017 16:37:43 +0000 Subject: [Archivesspace_Users_Group] AS upgrade advice needed In-Reply-To: References: Message-ID: <48FA188B-B7BA-4277-998F-9F0C85DCA7D0@eservices.virginia.edu> It?s always worked for me ( up to 1.5.1 - I haven?t tried 1.5.2 release yet ) to clone production database to test, run the setup-database script and start up archivesspace. 1.5.x startup takes quite a bit longer as it migrates to the new data model. So you shouldn?t have to install a test of 1.4.2 first. There?s also no reason not to go straight to 1.5.2. On Jan 11, 2017, at 11:15 AM, Cobourn, Alston > wrote: Dear all, I'm hoping some one can give me upgrade advice. We are currently using AS 1.4.2. Would it be best to upgrade straight from 1.4.2 to 1.5.2 or would it be best to upgrade incrementally? Relatedly, I'd like to do the upgrade first on a test server to make sure the shift in the underlying data model doesn't cause a huge problem for our data. We do not however currently have a test instance. Could I request IT set up a 1.5.2 test instance and import our data straight into that to answer this question or do I really need to have them set up a 1.4.2 test instance, import our data into that, and then upgrade that to 1.5.2. Thank you! Sincerely, Alston Cobourn Processing and Digital Assets Archivist Texas A&M-Corpus Christi 361-852-2300 alston.cobourn at tamucc.edu _______________________________________________ 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: From jhamblet at nmu.edu Wed Jan 11 12:52:27 2017 From: jhamblet at nmu.edu (Hambleton, John S) Date: Wed, 11 Jan 2017 17:52:27 +0000 Subject: [Archivesspace_Users_Group] AS upgrade advice needed In-Reply-To: <48FA188B-B7BA-4277-998F-9F0C85DCA7D0@eservices.virginia.edu> References: <48FA188B-B7BA-4277-998F-9F0C85DCA7D0@eservices.virginia.edu> Message-ID: <679d5d431b2f4beea04bafa68274de2c@EX01.ads.nmu.edu> I?m in this situation right now, that is, 1.4.2 in production, cloned production database to TEST, ran the setup-database script, and started up archivesspace 1.5.2. I did see in the archivesspace.out log: Completed: existing containers have been migrated to the new container model. So far so good. Then the indexer started, and immediately I saw: ?Error: Some library (perhaps JRuby) was built with a later JVM version. Please use libraries built with the version you intend to use or an earlier one.? OK, I tried updating java on the server (CentOS 6): From: java version "1.6.0_39" To: java version "1.8.0_102" Restart archivesspace, indexer started running! The only thing I?m not real sure of though, is how long it takes for the indexer to finish. I guess it would depend on how much data there is to index. If anyone has an idea of how to tell when the indexer has indexed everything, much obliged. John H NMU 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: Wednesday, January 11, 2017 11:38 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AS upgrade advice needed It?s always worked for me ( up to 1.5.1 - I haven?t tried 1.5.2 release yet ) to clone production database to test, run the setup-database script and start up archivesspace. 1.5.x startup takes quite a bit longer as it migrates to the new data model. So you shouldn?t have to install a test of 1.4.2 first. There?s also no reason not to go straight to 1.5.2. On Jan 11, 2017, at 11:15 AM, Cobourn, Alston > wrote: Dear all, I'm hoping some one can give me upgrade advice. We are currently using AS 1.4.2. Would it be best to upgrade straight from 1.4.2 to 1.5.2 or would it be best to upgrade incrementally? Relatedly, I'd like to do the upgrade first on a test server to make sure the shift in the underlying data model doesn't cause a huge problem for our data. We do not however currently have a test instance. Could I request IT set up a 1.5.2 test instance and import our data straight into that to answer this question or do I really need to have them set up a 1.4.2 test instance, import our data into that, and then upgrade that to 1.5.2. Thank you! Sincerely, Alston Cobourn Processing and Digital Assets Archivist Texas A&M-Corpus Christi 361-852-2300 alston.cobourn at tamucc.edu _______________________________________________ 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: From sdm7g at eservices.virginia.edu Wed Jan 11 13:12:54 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 11 Jan 2017 18:12:54 +0000 Subject: [Archivesspace_Users_Group] AS upgrade advice needed In-Reply-To: <679d5d431b2f4beea04bafa68274de2c@EX01.ads.nmu.edu> References: <48FA188B-B7BA-4277-998F-9F0C85DCA7D0@eservices.virginia.edu> <679d5d431b2f4beea04bafa68274de2c@EX01.ads.nmu.edu> Message-ID: <09FA5AE7-758C-47A6-94CE-50495AA75041@eservices.virginia.edu> On Jan 11, 2017, at 12:52 PM, Hambleton, John S > wrote: I?m in this situation right now, that is, 1.4.2 in production, cloned production database to TEST, ran the setup-database script, and started up archivesspace 1.5.2. I did see in the archivesspace.out log: Completed: existing containers have been migrated to the new container model. So far so good. Then the indexer started, and immediately I saw: ?Error: Some library (perhaps JRuby) was built with a later JVM version. Please use libraries built with the version you intend to use or an earlier one.? OK, I tried updating java on the server (CentOS 6): From: java version "1.6.0_39" To: java version "1.8.0_102" Restart archivesspace, indexer started running! The only thing I?m not real sure of though, is how long it takes for the indexer to finish. I guess it would depend on how much data there is to index. If anyone has an idea of how to tell when the indexer has indexed everything, much obliged. When your log file starts to echo this ?Running index round? without any intervening messages about what being indexed, that means it?s completed. 2017-01-11 11:38:45 -0500: Running index round 2017-01-11 11:39:16 -0500: Running index round 2017-01-11 11:39:46 -0500: Running index round 2017-01-11 11:40:17 -0500: Running index round 2017-01-11 11:40:47 -0500: Running index round Also, if you have more than one repository, it will index them in order and issue periodic messages like: Indexed 20475 of 24930 archival_object records in repository uva-hs so you can assume repositories before the current one have been indexed. John H NMU 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: Wednesday, January 11, 2017 11:38 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] AS upgrade advice needed It?s always worked for me ( up to 1.5.1 - I haven?t tried 1.5.2 release yet ) to clone production database to test, run the setup-database script and start up archivesspace. 1.5.x startup takes quite a bit longer as it migrates to the new data model. So you shouldn?t have to install a test of 1.4.2 first. There?s also no reason not to go straight to 1.5.2. On Jan 11, 2017, at 11:15 AM, Cobourn, Alston > wrote: Dear all, I'm hoping some one can give me upgrade advice. We are currently using AS 1.4.2. Would it be best to upgrade straight from 1.4.2 to 1.5.2 or would it be best to upgrade incrementally? Relatedly, I'd like to do the upgrade first on a test server to make sure the shift in the underlying data model doesn't cause a huge problem for our data. We do not however currently have a test instance. Could I request IT set up a 1.5.2 test instance and import our data straight into that to answer this question or do I really need to have them set up a 1.4.2 test instance, import our data into that, and then upgrade that to 1.5.2. Thank you! Sincerely, Alston Cobourn Processing and Digital Assets Archivist Texas A&M-Corpus Christi 361-852-2300 alston.cobourn at tamucc.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhamblet at nmu.edu Wed Jan 11 13:23:56 2017 From: jhamblet at nmu.edu (Hambleton, John S) Date: Wed, 11 Jan 2017 18:23:56 +0000 Subject: [Archivesspace_Users_Group] AS upgrade advice needed In-Reply-To: <09FA5AE7-758C-47A6-94CE-50495AA75041@eservices.virginia.edu> References: <48FA188B-B7BA-4277-998F-9F0C85DCA7D0@eservices.virginia.edu> <679d5d431b2f4beea04bafa68274de2c@EX01.ads.nmu.edu> <09FA5AE7-758C-47A6-94CE-50495AA75041@eservices.virginia.edu> Message-ID: <5ca998d8a9264017b95b73b6f36988d6@EX01.ads.nmu.edu> Many thanks, Steven! 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: Wednesday, January 11, 2017 1:13 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AS upgrade advice needed On Jan 11, 2017, at 12:52 PM, Hambleton, John S > wrote: I?m in this situation right now, that is, 1.4.2 in production, cloned production database to TEST, ran the setup-database script, and started up archivesspace 1.5.2. I did see in the archivesspace.out log: Completed: existing containers have been migrated to the new container model. So far so good. Then the indexer started, and immediately I saw: ?Error: Some library (perhaps JRuby) was built with a later JVM version. Please use libraries built with the version you intend to use or an earlier one.? OK, I tried updating java on the server (CentOS 6): From: java version "1.6.0_39" To: java version "1.8.0_102" Restart archivesspace, indexer started running! The only thing I?m not real sure of though, is how long it takes for the indexer to finish. I guess it would depend on how much data there is to index. If anyone has an idea of how to tell when the indexer has indexed everything, much obliged. When your log file starts to echo this ?Running index round? without any intervening messages about what being indexed, that means it?s completed. 2017-01-11 11:38:45 -0500: Running index round 2017-01-11 11:39:16 -0500: Running index round 2017-01-11 11:39:46 -0500: Running index round 2017-01-11 11:40:17 -0500: Running index round 2017-01-11 11:40:47 -0500: Running index round Also, if you have more than one repository, it will index them in order and issue periodic messages like: Indexed 20475 of 24930 archival_object records in repository uva-hs so you can assume repositories before the current one have been indexed. John H NMU 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: Wednesday, January 11, 2017 11:38 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] AS upgrade advice needed It?s always worked for me ( up to 1.5.1 - I haven?t tried 1.5.2 release yet ) to clone production database to test, run the setup-database script and start up archivesspace. 1.5.x startup takes quite a bit longer as it migrates to the new data model. So you shouldn?t have to install a test of 1.4.2 first. There?s also no reason not to go straight to 1.5.2. On Jan 11, 2017, at 11:15 AM, Cobourn, Alston > wrote: Dear all, I'm hoping some one can give me upgrade advice. We are currently using AS 1.4.2. Would it be best to upgrade straight from 1.4.2 to 1.5.2 or would it be best to upgrade incrementally? Relatedly, I'd like to do the upgrade first on a test server to make sure the shift in the underlying data model doesn't cause a huge problem for our data. We do not however currently have a test instance. Could I request IT set up a 1.5.2 test instance and import our data straight into that to answer this question or do I really need to have them set up a 1.4.2 test instance, import our data into that, and then upgrade that to 1.5.2. Thank you! Sincerely, Alston Cobourn Processing and Digital Assets Archivist Texas A&M-Corpus Christi 361-852-2300 alston.cobourn at tamucc.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhamblet at nmu.edu Wed Jan 11 13:57:49 2017 From: jhamblet at nmu.edu (Hambleton, John S) Date: Wed, 11 Jan 2017 18:57:49 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 Message-ID: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jswierc1 at swarthmore.edu Wed Jan 11 16:09:39 2017 From: jswierc1 at swarthmore.edu (Julie Swierczek) Date: Wed, 11 Jan 2017 16:09:39 -0500 Subject: [Archivesspace_Users_Group] MARCXML importer - 710 fields problem Message-ID: I'm testing the MARCXML importer and I've run into a problem. I have multiple 710 fields with ind1=2 and ind2=[blank]. According to the import map, these should import as agents with the role of 'creator'. However, they are importing as agents with the role of 'subject'. There are too many to manually fix. Any ideas on how to get this to work properly? Thanks. -- Julie C. Swierczek Librarian for Primary Resources and Metadata Services Swarthmore College Peace Collection and Friends Historical Library -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Wed Jan 11 16:17:43 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 11 Jan 2017 21:17:43 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> Message-ID: <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> 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 > 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From mang.sun at rice.edu Wed Jan 11 16:32:11 2017 From: mang.sun at rice.edu (Mang Sun) Date: Wed, 11 Jan 2017 15:32:11 -0600 Subject: [Archivesspace_Users_Group] Any ArchivesSpace tech guys going to Code4Lib2017? Message-ID: Any ArchivesSpace tech guys/developers going to Code4Lib2017? Mang Sun Rice U. From james at hudmol.com Wed Jan 11 18:56:26 2017 From: james at hudmol.com (James Bullen) Date: Thu, 12 Jan 2017 10:56:26 +1100 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> Message-ID: <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> 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) 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 > 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 >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > !DSPAM:5876a103173858981945283! > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:5876a103173858981945283! -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Thu Jan 12 08:46:09 2017 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 12 Jan 2017 13:46:09 +0000 Subject: [Archivesspace_Users_Group] Any ArchivesSpace tech guys going to Code4Lib2017? Message-ID: Laney McGlohon, the new ArchivesSpace Technical Lead, will be attending Code4Lib this year. ArchivesSpace and LYRASIS will also have a joint booth at the conference. She's really looking forward to catching up with people in person and getting discussions going about all things having to do with development and ArchivesSpace. Laney officially starts with the program on January 23 and will be looking for ideas and sharing details of ArchivesSpace activities at Code4Lib once she has settled in. In the interim, if anyone has ideas or has already made plans for Code4Lib that include or relate to ArchivesSpace, feel free to share them here. Christine Christine Di Bella ArchivesSpace Community Outreach 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 Mang Sun Sent: Wednesday, January 11, 2017 4:32 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Any ArchivesSpace tech guys going to Code4Lib2017? Any ArchivesSpace tech guys/developers going to Code4Lib2017? Mang Sun Rice U. _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From jhamblet at nmu.edu Thu Jan 12 09:30:53 2017 From: jhamblet at nmu.edu (Hambleton, John S) Date: Thu, 12 Jan 2017 14:30:53 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> Message-ID: <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> 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] On Behalf Of James Bullen Sent: Wednesday, January 11, 2017 6:56 PM To: Archivesspace Users Group 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) > 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 > 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Thu Jan 12 10:42:24 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Thu, 12 Jan 2017 15:42:24 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> Message-ID: I?m trying to identify the data where it breaks. It looks like it gets the first 275 archival objects in the first repo indexed. But I haven?t yet figured out which one that is or seen anything different in the region where it fails. But I can send you the whole 8MB gzip compressed mysqldump if you want to try to investigate. ? Steve. On Jan 11, 2017, at 6:54 PM, James Bullen > wrote: 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) > 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 > 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ 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: From mang.sun at rice.edu Thu Jan 12 10:59:18 2017 From: mang.sun at rice.edu (Mang Sun) Date: Thu, 12 Jan 2017 09:59:18 -0600 Subject: [Archivesspace_Users_Group] Any ArchivesSpace tech guys going to Code4Lib2017? In-Reply-To: References: Message-ID: <7866510a-04a1-ef6b-f83f-6a9bbcb57fcf@rice.edu> That's perfect.Thank you Christine! Mang On 1/12/2017 7:46 AM, Christine Di Bella wrote: > Laney McGlohon, the new ArchivesSpace Technical Lead, will be attending Code4Lib this year. ArchivesSpace and LYRASIS will also have a joint booth at the conference. She's really looking forward to catching up with people in person and getting discussions going about all things having to do with development and ArchivesSpace. > > Laney officially starts with the program on January 23 and will be looking for ideas and sharing details of ArchivesSpace activities at Code4Lib once she has settled in. In the interim, if anyone has ideas or has already made plans for Code4Lib that include or relate to ArchivesSpace, feel free to share them here. > > Christine > > Christine Di Bella > ArchivesSpace Community Outreach 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 Mang Sun > Sent: Wednesday, January 11, 2017 4:32 PM > To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] Any ArchivesSpace tech guys going to Code4Lib2017? > > Any ArchivesSpace tech guys/developers going to Code4Lib2017? > > Mang Sun > Rice U. > > _______________________________________________ > 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 mang.sun at rice.edu Thu Jan 12 13:47:14 2017 From: mang.sun at rice.edu (Mang Sun) Date: Thu, 12 Jan 2017 12:47:14 -0600 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> Message-ID: <69ff51fc-1ea9-d7bc-5b52-a1ef1abd1939@rice.edu> Steve, You are not alone. We also ran into indexing error when trying to test upgrade v1.5.1 to v.1.5.2 and see no record found again after the test upgrade. LYRASIS Support Desk ever helped us in solving a similar indexing problem (no record found ) which ever drove me mad :) when upgrading 1.4.2 to 1.5.1. I hope there could be more technical document or white paper on the indexing part which could help us do better understanding of the indexing logic and architecture, and consequently could help us do better troubleshooting work. Mang On 1/12/2017 9:42 AM, Majewski, Steven Dennis (sdm7g) wrote: > > I?m trying to identify the data where it breaks. It looks like it gets > the first 275 archival objects in the first repo indexed. But I > haven?t yet figured out which one that is or seen anything different > in the region where it fails. But I can send you the whole 8MB gzip > compressed mysqldump if you want to try to investigate. > > ? Steve. > > > >> On Jan 11, 2017, at 6:54 PM, James Bullen > > wrote: >> >> >> 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) >>> > >>> 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 >>> > 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 >>>> >>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> >>> !DSPAM:5876a103173858981945283! >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> Archivesspace_Users_Group at lyralists.lyrasis.org >>> >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> >>> >>> !DSPAM:5876a103173858981945283! >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltang5 at mail.lib.msu.edu Thu Jan 12 13:52:19 2017 From: ltang5 at mail.lib.msu.edu (Tang, Lydia) Date: Thu, 12 Jan 2017 18:52:19 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <69ff51fc-1ea9-d7bc-5b52-a1ef1abd1939@rice.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <69ff51fc-1ea9-d7bc-5b52-a1ef1abd1939@rice.edu> Message-ID: We are also currently experiencing this issue as well. If I find out more of what our problem is, I?ll send that along later! Lydia -- Dr. Lydia Tang Special Collections Archivist-Librarian Michigan State University Libraries From: on behalf of Mang Sun Reply-To: Archivesspace Users Group Date: Thursday, January 12, 2017 at 1:47 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 Steve, You are not alone. We also ran into indexing error when trying to test upgrade v1.5.1 to v.1.5.2 and see no record found again after the test upgrade. LYRASIS Support Desk ever helped us in solving a similar indexing problem (no record found ) which ever drove me mad :) when upgrading 1.4.2 to 1.5.1. I hope there could be more technical document or white paper on the indexing part which could help us do better understanding of the indexing logic and architecture, and consequently could help us do better troubleshooting work. Mang On 1/12/2017 9:42 AM, Majewski, Steven Dennis (sdm7g) wrote: I?m trying to identify the data where it breaks. It looks like it gets the first 275 archival objects in the first repo indexed. But I haven?t yet figured out which one that is or seen anything different in the region where it fails. But I can send you the whole 8MB gzip compressed mysqldump if you want to try to investigate. ? Steve. On Jan 11, 2017, at 6:54 PM, James Bullen > wrote: 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) > 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 > 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ 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 sdm7g at eservices.virginia.edu Thu Jan 12 18:08:16 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Thu, 12 Jan 2017 23:08:16 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <69ff51fc-1ea9-d7bc-5b52-a1ef1abd1939@rice.edu> Message-ID: I changes indexer values in config.rb AppConfig[:indexer_records_per_thread] = 1 AppConfig[:indexer_thread_count] = 1 and added some extra debug output to backend logs and was able to identify which record it fails on. Looking at that record in production 1.4.2, it?s not obvious to me that there?s a significant different that causes this one to fail. However, when I look at it in the existing test 1.5.1 server, I see that it is missing info in the instance. The highlighted archival_object should say ?Box: Artifacts 1? with a barcode just as the record below does. So perhaps something was failing silently in the 1.5.1 migration, which only now triggers an error in 1.5.2 . I will be investigating this further? [cid:24FADF87-091C-448B-83E8-99973D11E8B0 at virginia.edu] [cid:2042A5DB-1D34-4C05-84AD-40E4E9811CE2 at virginia.edu] On Jan 12, 2017, at 1:52 PM, Tang, Lydia > wrote: We are also currently experiencing this issue as well. If I find out more of what our problem is, I?ll send that along later! Lydia -- Dr. Lydia Tang Special Collections Archivist-Librarian Michigan State University Libraries From: > on behalf of Mang Sun > Reply-To: Archivesspace Users Group > Date: Thursday, January 12, 2017 at 1:47 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 Steve, You are not alone. We also ran into indexing error when trying to test upgrade v1.5.1 to v.1.5.2 and see no record found again after the test upgrade. LYRASIS Support Desk ever helped us in solving a similar indexing problem (no record found ) which ever drove me mad :) when upgrading 1.4.2 to 1.5.1. I hope there could be more technical document or white paper on the indexing part which could help us do better understanding of the indexing logic and architecture, and consequently could help us do better troubleshooting work. Mang On 1/12/2017 9:42 AM, Majewski, Steven Dennis (sdm7g) wrote: I?m trying to identify the data where it breaks. It looks like it gets the first 275 archival objects in the first repo indexed. But I haven?t yet figured out which one that is or seen anything different in the region where it fails. But I can send you the whole 8MB gzip compressed mysqldump if you want to try to investigate. ? Steve. On Jan 11, 2017, at 6:54 PM, James Bullen > wrote: 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) > 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 > 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:5876a103173858981945283! _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: record.v1.5.1.png Type: image/png Size: 513940 bytes Desc: record.v1.5.1.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bottomrecord.v1.5.1.png Type: image/png Size: 348066 bytes Desc: bottomrecord.v1.5.1.png URL: From bfinberg at okeeffemuseum.org Thu Jan 12 19:54:05 2017 From: bfinberg at okeeffemuseum.org (Ben Finberg) Date: Fri, 13 Jan 2017 00:54:05 +0000 Subject: [Archivesspace_Users_Group] FW: Help upgrading ArchivesSpace on a Windows/MySQL system In-Reply-To: References: <20161206105208.Horde.P0Chkd1jwBA-DcnSAY58Uqz@gator3088.hostgator.com> <37B02ED8-D2AC-4C49-9CF2-F0E3A4063144@lyrasis.org> Message-ID: Belated follow-up now that I?ve got this running, big thanks to Blake at Lyrasis for helping with the non-Windows-specific portion of the upgrade. There were several things I was doing wrong: ? At one point I was copying over some of the data directory, which turned out to be unnecessary. ? At another point I had the MySQL server stopped during the upgrade, and it needs to be on to do the upgrade properly. ? Most important: you may need to delete and recreate your ArchivesSpace Windows service. Even if it?s in the exact same location after the upgrade, it won?t necessarily work anymore. Since the Windows/MySQL install instructions I typed up last year seemed to be helpful, I?ve typed up a new set of instructions for the upgrade; I hope this will help some people. Best, Ben Benjamin Finberg, Director of IT and Operations The Georgia O?Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O?Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Laurie Arp Sent: Thursday, December 8, 2016 5:17 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] FW: Help upgrading ArchivesSpace on a Windows/MySQL system Hello Ben, I had the team look into this. They tested 1.5.2-RC1 as a service on windows and it worked fine. So, I wonder if there is another issue. I can have the DTS folks follow up with you to see if they can help. In answer to the query about the roadmap itself, yes we are working on a development roadmap that will provide more specifics as to content and dates and we hope to share more details soon. Best wishes, Laurie Gemmill Arp Director, Collections Services & Community Supported Software laurie.arp at lyrasis.org 800.999.8558 x 2908 -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ben Finberg Sent: Tuesday, December 6, 2016 12:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Help upgrading ArchivesSpace on a Windows/MySQL system Really? That's kind of crazy. Does anyone know if it's in the roadmap to make it work as a service again? -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of library at princeofpeaceabbey.org Sent: Tuesday, December 6, 2016 9:52 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Help upgrading ArchivesSpace on a Windows/MySQL system Ben, I had the same problem. Chris told me that AS 1.5 will not run as a service. So I have to load it the old way. Br Raphael Quoting Ben Finberg >: Hoping for some help upgrading ArchivesSpace from 1.4.7 to 1.5.1 running Windows Server 2008 R2 and MySQL. I've tried following the main and supplemental 1.4.x to 1.5.x instructions several times and I keep finishing and getting HTTP ERROR 503 service unavailable. Here are the steps I'm doing: 1) Backup. 2) Delete data/solr_index/index directory. Delete all files in data/indexer_state directory. 3) Unzip AS download. 4) Shutdown AS service 5) Rename old AS directory from ArchivesSpace to ArchivesSpace.old 6) Name new AS directory ArhichivesSpace 7) Copy data directory from ArchivesSpace.old to ArchivesSpace, replace all files when prompted. 8) Make three edits in new config.rb file for db_url and jetty as described in clean install instructions. 9) Copy mysql-connector*.jar to new \lib directory. 10) Copy prunmgr and prunsrv to new ArchivesSpace directory. 11) (I don't have any plugins or mods.) 12) Running a command prompt as an admin, run setup-database.bat in the new \scripts folder, then service.bat in the new \launcher folder. 13) Start service. So? Thoughts on what I might be doing wrong? Benjamin Finberg, Director of IT and Operations The Georgia O'Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org> A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O'Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. _______________________________________________ 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 !DSPAM:5848284433581391476495! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfinberg at okeeffemuseum.org Thu Jan 12 20:09:06 2017 From: bfinberg at okeeffemuseum.org (Ben Finberg) Date: Fri, 13 Jan 2017 01:09:06 +0000 Subject: [Archivesspace_Users_Group] Upgrading ArchivesSpace on a Windows/MySQL server: my step-by-step instructions Message-ID: Hi everyone, As with the official installation documentation for ArchivesSpace on Windows/MySQL, I had a fair amount of trouble following the official upgrade documentation and getting everything to work properly, especially running as a service. I've typed up a set of step-by-step instructions that helped me; I hope they're helpful to somebody else as well. NB two caveats: * These instructions assume you're using all the default locations/names, and you have no customizations. * Whereas I did a bunch of screenshots in the earlier instructions for a clean install, I've made these a lot terser; I figure if you made it through the original install you should be able to follow these steps without too much trouble. Ben P.S. When time permits I'll try to do a YouTube recording of this as well. Benjamin Finberg, Director of IT and Operations The Georgia O'Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O'Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: How to upgrade ArchivesSpace on a Windows server.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 14428 bytes Desc: How to upgrade ArchivesSpace on a Windows server.docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: How to upgrade ArchivesSpace on a Windows server.pdf Type: application/pdf Size: 475134 bytes Desc: How to upgrade ArchivesSpace on a Windows server.pdf URL: From james at hudmol.com Thu Jan 12 23:39:28 2017 From: james at hudmol.com (James Bullen) Date: Fri, 13 Jan 2017 15:39:28 +1100 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> Message-ID: <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> 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 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 ] On Behalf Of James Bullen > Sent: Wednesday, January 11, 2017 6:56 PM > To: Archivesspace Users Group > > 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) > 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 > 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 > 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 > > > !DSPAM:5876a103173858981945283! > > !DSPAM:587793334611909212977! _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:587793334611909212977! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhamblet at nmu.edu Fri Jan 13 09:36:53 2017 From: jhamblet at nmu.edu (Hambleton, John S) Date: Fri, 13 Jan 2017 14:36:53 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> Message-ID: I would like to publicly thank James for his efforts and quick response in helping us with this matter! John H NMU From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of James Bullen Sent: Thursday, January 12, 2017 11:39 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 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 > 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] On Behalf Of James Bullen Sent: Wednesday, January 11, 2017 6:56 PM To: Archivesspace Users Group > 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) > 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 > 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 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 !DSPAM:5876a103173858981945283! !DSPAM:587793334611909212977! _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:587793334611909212977! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Fri Jan 13 16:37:32 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 13 Jan 2017 21:37:32 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> Message-ID: <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> 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 > 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 > 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] On Behalf Of James Bullen Sent: Wednesday, January 11, 2017 6:56 PM To: Archivesspace Users Group > 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) > 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 > 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 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 !DSPAM:5876a103173858981945283! !DSPAM:587793334611909212977! _______________________________________________ Archivesspace_Users_Group mailing list 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at hudmol.com Fri Jan 13 18:15:38 2017 From: james at hudmol.com (James Bullen) Date: Sat, 14 Jan 2017 10:15:38 +1100 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> Message-ID: 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 > On Jan 14, 2017, at 8:37 AM, Majewski, Steven Dennis (sdm7g) 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 > 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 > 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 ] On Behalf Of James Bullen >>> Sent: Wednesday, January 11, 2017 6:56 PM >>> To: Archivesspace Users Group > >>> 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) > 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 > 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 >>> 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 >>> >>> >>> >>> !DSPAM:587793334611909212977! _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> 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 >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > !DSPAM:587948af109451970717657! > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:587948af109451970717657! -------------- next part -------------- An HTML attachment was scrubbed... URL: From KUTZUBA at hws.edu Mon Jan 16 14:06:43 2017 From: KUTZUBA at hws.edu (Kutzuba, Jamie) Date: Mon, 16 Jan 2017 19:06:43 +0000 Subject: [Archivesspace_Users_Group] FW: Help upgrading ArchivesSpace on a Windows/MySQL system In-Reply-To: References: <20161206105208.Horde.P0Chkd1jwBA-DcnSAY58Uqz@gator3088.hostgator.com> <37B02ED8-D2AC-4C49-9CF2-F0E3A4063144@lyrasis.org> Message-ID: <9b1f89a7ed9547c2a5698ce6738909b0@EXCH13MBX1.hws.edu> Thanks Ben and Laurie for this information! - Jamie Jamie Kutzuba Systems Librarian 315.781.4355 Warren Hunting Smith Library Hobart & William Smith Colleges From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ben Finberg Sent: Thursday, January 12, 2017 7:54 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] FW: Help upgrading ArchivesSpace on a Windows/MySQL system Belated follow-up now that I?ve got this running, big thanks to Blake at Lyrasis for helping with the non-Windows-specific portion of the upgrade. There were several things I was doing wrong: ? At one point I was copying over some of the data directory, which turned out to be unnecessary. ? At another point I had the MySQL server stopped during the upgrade, and it needs to be on to do the upgrade properly. ? Most important: you may need to delete and recreate your ArchivesSpace Windows service. Even if it?s in the exact same location after the upgrade, it won?t necessarily work anymore. Since the Windows/MySQL install instructions I typed up last year seemed to be helpful, I?ve typed up a new set of instructions for the upgrade; I hope this will help some people. Best, Ben Benjamin Finberg, Director of IT and Operations The Georgia O?Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O?Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Laurie Arp Sent: Thursday, December 8, 2016 5:17 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] FW: Help upgrading ArchivesSpace on a Windows/MySQL system Hello Ben, I had the team look into this. They tested 1.5.2-RC1 as a service on windows and it worked fine. So, I wonder if there is another issue. I can have the DTS folks follow up with you to see if they can help. In answer to the query about the roadmap itself, yes we are working on a development roadmap that will provide more specifics as to content and dates and we hope to share more details soon. Best wishes, Laurie Gemmill Arp Director, Collections Services & Community Supported Software laurie.arp at lyrasis.org 800.999.8558 x 2908 -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ben Finberg Sent: Tuesday, December 6, 2016 12:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Help upgrading ArchivesSpace on a Windows/MySQL system Really? That's kind of crazy. Does anyone know if it's in the roadmap to make it work as a service again? -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of library at princeofpeaceabbey.org Sent: Tuesday, December 6, 2016 9:52 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Help upgrading ArchivesSpace on a Windows/MySQL system Ben, I had the same problem. Chris told me that AS 1.5 will not run as a service. So I have to load it the old way. Br Raphael Quoting Ben Finberg >: Hoping for some help upgrading ArchivesSpace from 1.4.7 to 1.5.1 running Windows Server 2008 R2 and MySQL. I've tried following the main and supplemental 1.4.x to 1.5.x instructions several times and I keep finishing and getting HTTP ERROR 503 service unavailable. Here are the steps I'm doing: 1) Backup. 2) Delete data/solr_index/index directory. Delete all files in data/indexer_state directory. 3) Unzip AS download. 4) Shutdown AS service 5) Rename old AS directory from ArchivesSpace to ArchivesSpace.old 6) Name new AS directory ArhichivesSpace 7) Copy data directory from ArchivesSpace.old to ArchivesSpace, replace all files when prompted. 8) Make three edits in new config.rb file for db_url and jetty as described in clean install instructions. 9) Copy mysql-connector*.jar to new \lib directory. 10) Copy prunmgr and prunsrv to new ArchivesSpace directory. 11) (I don't have any plugins or mods.) 12) Running a command prompt as an admin, run setup-database.bat in the new \scripts folder, then service.bat in the new \launcher folder. 13) Start service. So? Thoughts on what I might be doing wrong? Benjamin Finberg, Director of IT and Operations The Georgia O'Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org> A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O'Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. _______________________________________________ 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 !DSPAM:5848284433581391476495! -------------- next part -------------- An HTML attachment was scrubbed... URL: From KUTZUBA at hws.edu Mon Jan 16 14:07:04 2017 From: KUTZUBA at hws.edu (Kutzuba, Jamie) Date: Mon, 16 Jan 2017 19:07:04 +0000 Subject: [Archivesspace_Users_Group] Upgrading ArchivesSpace on a Windows/MySQL server: my step-by-step instructions In-Reply-To: References: Message-ID: <7f241faf8ec642829b6e685937c2b274@EXCH13MBX1.hws.edu> Thanks for documenting this! - Jamie 315.781.4355 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ben Finberg Sent: Thursday, January 12, 2017 8:09 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Upgrading ArchivesSpace on a Windows/MySQL server: my step-by-step instructions Hi everyone, As with the official installation documentation for ArchivesSpace on Windows/MySQL, I had a fair amount of trouble following the official upgrade documentation and getting everything to work properly, especially running as a service. I've typed up a set of step-by-step instructions that helped me; I hope they're helpful to somebody else as well. NB two caveats: * These instructions assume you're using all the default locations/names, and you have no customizations. * Whereas I did a bunch of screenshots in the earlier instructions for a clean install, I've made these a lot terser; I figure if you made it through the original install you should be able to follow these steps without too much trouble. Ben P.S. When time permits I'll try to do a YouTube recording of this as well. Benjamin Finberg, Director of IT and Operations The Georgia O'Keeffe Museum 505.946.1057 217 Johnson St., Santa Fe, NM 87501 www.okeeffemuseum.org A Great American Artist, a Great American Story. Explore the remarkable career of Georgia O'Keeffe through her artwork, the objects and places that were meaningful to her, and the experiences that defined her life. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurie.arp at lyrasis.org Wed Jan 18 11:15:39 2017 From: laurie.arp at lyrasis.org (Laurie Arp) Date: Wed, 18 Jan 2017 16:15:39 +0000 Subject: [Archivesspace_Users_Group] New ArchivesSpace Program Manager: Christine Di Bella Message-ID: LYRASIS, the organizational home for ArchivesSpace, is delighted to announce that Christine Di Bella is the new ArchivesSpace Program Manager! Christine's extensive knowledge of ArchivesSpace, her close connection to its community, and her deep and varied experience in the archival profession all make her uniquely well-qualified for this position. As Program Manager, Christine will play a key role working with the community to set the strategy and goals for ArchivesSpace. The Program Manager is central to the success of the program, and works closely and collaboratively with the ArchivesSpace community, advisory groups and Board to ensure success. Christine will be involved in all aspects of the program, and serve as a key spokesperson and advocate for the program. Christine has been with LYRASIS's ArchivesSpace team since 2014. In her most recent role as Community Outreach Manager she participated in a number of activities to strengthen the program and engage our community in its future in part by improving both the quality and timeliness of our communication to members and non-members. She managed the ArchivesSpace training program and led the planning efforts for the 2015 and 2016 Member Forums. While at LYRASIS, Christine been a critical contributor to both ArchivesSpace and LYRASIS programs and services. This important relationship between ArchivesSpace and LYRASIS will be served by having such a dedicated member of both teams in this position. Before joining the ArchivesSpace team, Christine managed the archives at the Institute for Advanced Study, led a consortial survey project for the Philadelphia Area Consortium of Special Collections Libraries (PACSCL), and worked on large processing projects at institutions including the 92nd Street Y and the University of Michigan. Christine earned her Bachelor's degree in English from Wesleyan University and her Masters of Science in Information from the School of Information at the University of Michigan. She also holds a Digital Archives Specialist (DAS) certificate from the Society of American Archivists. Christine and Laney McGlohon, the ArchivesSpace Tech Lead, report to Laurie Arp, LYRASIS's Director of Collections Services & Community Supported Software. They will work together to support the ArchivesSpace community and improve the ArchivesSpace application. Christine's new role is effective immediately. Please join us in congratulating Christine on her new role! Laurie Gemmill Arp Director, Collections Services & Community Supported Software laurie.arp at lyrasis.org 800.999.8558 x 2908 Fax: 404.592.4804 laurie.gemmill1 Skype [cid:D9C43C04-DF4E-467C-B0BC-358EF417F998] Check lyrasisnow.org for up-to-date news and feature articles. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4483 bytes Desc: image001.png URL: From gordon_daines at byu.edu Thu Jan 19 14:58:14 2017 From: gordon_daines at byu.edu (Gordon Daines) Date: Thu, 19 Jan 2017 19:58:14 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace User Advisory Council meeting minutes (January 17, 2017) Message-ID: All, The minutes for the User Advisory Council meeting are now available at https://archivesspace.atlassian.net/wiki/display/AC/2017-1-17+User+Advisory+Council+Meeting. You can follow along - or comment/get involved - with the activities of the UAC and its sub-teams on the wiki at https://archivesspace.atlassian.net/wiki/display/AC/Users+Advisory+Council. Gordon _________________________ J. Gordon Daines III Supervisor of Reference Services Department Chair L. Tom Perry Special Collections Brigham Young University Provo, UT 84602 801-422-5821 gordon_daines at byu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kate_bowers at harvard.edu Fri Jan 20 11:15:59 2017 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Fri, 20 Jan 2017 16:15:59 +0000 Subject: [Archivesspace_Users_Group] is not exported to EAD for archival objects Message-ID: is not getting exported to EAD from ArchivesSpace resources. Is anyone else having this experience? There is a related JIRA issue, https://archivesspace.atlassian.net/browse/AR-1459 Can anyone explain why these agents are not being exported to EAD? Screenshot: EAD result: Roscoe Simmons, full-length portrait, sitting in wicker chair, turned to the left, HUM 2.85 (1) 1 photographsgelatin silver print ;print 16 x 10 cm) 1915 HUM 2.85 Box 1 Folder 1 Source of information

Title devised.

 Biographical / Historical

Considered the most successful African American photographer in Louisville, Kentucky, Arthur P. Evans opened his studio in 1905 and remained in business until the 1960s.

 Description

Studio portrait.

 General

Blind stamp: Evans Studio, Louisville, Ky.

 Simmons, Roscoe Conkling, 1881-1951 Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu voice: (617) 998-5238 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 34911 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From buschedw at campusad.msu.edu Fri Jan 20 12:03:47 2017 From: buschedw at campusad.msu.edu (Busch, Ed) Date: Fri, 20 Jan 2017 17:03:47 +0000 Subject: [Archivesspace_Users_Group] is not exported to EAD for archival objects In-Reply-To: References: Message-ID: <35E2A8E8997F6C48A5D5FC21602BDEB6DDB04E8D@CAD-EX01.campusad.msu.edu> What version of ASpace are you running? I believe the fix went in on 1.5.2. Ed Busch Electronic Records Archivist MSU Archives 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: Friday, January 20, 2017 11:16 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] is not exported to EAD for archival objects is not getting exported to EAD from ArchivesSpace resources. Is anyone else having this experience? There is a related JIRA issue, https://archivesspace.atlassian.net/browse/AR-1459 Can anyone explain why these agents are not being exported to EAD? Screenshot: [cid:image001.jpg at 01D27315.3FEF4AC0] EAD result: Roscoe Simmons, full-length portrait, sitting in wicker chair, turned to the left, HUM 2.85 (1) 1 photographsgelatin silver print ;print 16 x 10 cm) 1915 HUM 2.85 Box 1 Folder 1 Source of information

Title devised.

 Biographical / Historical

Considered the most successful African American photographer in Louisville, Kentucky, Arthur P. Evans opened his studio in 1905 and remained in business until the 1960s.

 Description

Studio portrait.

 General

Blind stamp: Evans Studio, Louisville, Ky.

 Simmons, Roscoe Conkling, 1881-1951 Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu voice: (617) 998-5238 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 34911 bytes Desc: image001.jpg URL: From kate_bowers at harvard.edu Fri Jan 20 12:21:22 2017 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Fri, 20 Jan 2017 17:21:22 +0000 Subject: [Archivesspace_Users_Group] is not exported to EAD for archival objects In-Reply-To: <35E2A8E8997F6C48A5D5FC21602BDEB6DDB04E8D@CAD-EX01.campusad.msu.edu> References: <35E2A8E8997F6C48A5D5FC21602BDEB6DDB04E8D@CAD-EX01.campusad.msu.edu> Message-ID: Thanks! We're running v1.5.1.1. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Friday, January 20, 2017 12:04 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] is not exported to EAD for archival objects What version of ASpace are you running? I believe the fix went in on 1.5.2. Ed Busch Electronic Records Archivist MSU Archives 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: Friday, January 20, 2017 11:16 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] is not exported to EAD for archival objects is not getting exported to EAD from ArchivesSpace resources. Is anyone else having this experience? There is a related JIRA issue, https://archivesspace.atlassian.net/browse/AR-1459 Can anyone explain why these agents are not being exported to EAD? Screenshot: [cid:image001.jpg at 01D27317.B4F590C0] EAD result: Roscoe Simmons, full-length portrait, sitting in wicker chair, turned to the left, HUM 2.85 (1) 1 photographsgelatin silver print ;print 16 x 10 cm) 1915 HUM 2.85 Box 1 Folder 1 Source of information

Title devised.

 Biographical / Historical

Considered the most successful African American photographer in Louisville, Kentucky, Arthur P. Evans opened his studio in 1905 and remained in business until the 1960s.

 Description

Studio portrait.

 General

Blind stamp: Evans Studio, Louisville, Ky.

 Simmons, Roscoe Conkling, 1881-1951 Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu voice: (617) 998-5238 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 34911 bytes Desc: image001.jpg URL: From sdm7g at eservices.virginia.edu Fri Jan 20 15:49:05 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 20 Jan 2017 20:49:05 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> Message-ID: On Jan 13, 2017, at 6:15 PM, James Bullen > 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 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 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 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) > 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 > 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 > 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] On Behalf Of James Bullen Sent: Wednesday, January 11, 2017 6:56 PM To: Archivesspace Users Group > 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) > 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 > 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 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 !DSPAM:587793334611909212977! _______________________________________________ Archivesspace_Users_Group mailing list 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:587948af109451970717657! _______________________________________________ Archivesspace_Users_Group mailing list 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7ebc58861f8c38997d24d1316e9276ec Type: application/octet-stream Size: 5685 bytes Desc: 7ebc58861f8c38997d24d1316e9276ec URL: From laurie.arp at lyrasis.org Mon Jan 23 10:24:07 2017 From: laurie.arp at lyrasis.org (Laurie Arp) Date: Mon, 23 Jan 2017 15:24:07 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Technology and Development Roadmap Message-ID: Greetings, The ArchivesSpace team is pleased to share the draft ArchivesSpace Technology and Development Roadmap with the community. This roadmap is a planning and communication tool to help the community know what to expect in terms of future development work and aid in planning for upcoming releases and application upgrades. Attached is the roadmap and accompanying narrative that provides some context and background for the roadmap. Please feel free to share your feedback with us at ArchivesSpaceHome at lyrasis.org. Best wishes, Laurie Gemmill Arp Director, Collections Services & Community Supported Software laurie.arp at lyrasis.org 800.999.8558 x 2908 Fax: 404.592.4804 laurie.gemmill1 Skype [cid:D9C43C04-DF4E-467C-B0BC-358EF417F998] Check lyrasisnow.org for up-to-date news and feature articles. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4483 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ASRoadMapNarrative201701.pdf Type: application/pdf Size: 353557 bytes Desc: ASRoadMapNarrative201701.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ASpaceRoadMap201701.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 18700 bytes Desc: ASpaceRoadMap201701.xlsx URL: From sdm7g at eservices.virginia.edu Mon Jan 23 14:54:53 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 23 Jan 2017 19:54:53 +0000 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> Message-ID: <1B0EA75C-EE19-492A-B057-FBAEFBBFB880@eservices.virginia.edu> 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) > wrote: On Jan 13, 2017, at 6:15 PM, James Bullen > 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 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 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 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) > 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 > 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 > 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] On Behalf Of James Bullen Sent: Wednesday, January 11, 2017 6:56 PM To: Archivesspace Users Group > 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) > 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 > 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 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 !DSPAM:587793334611909212977! _______________________________________________ Archivesspace_Users_Group mailing list 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:587948af109451970717657! _______________________________________________ Archivesspace_Users_Group mailing list 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 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <7ebc58861f8c38997d24d1316e9276ec>_______________________________________________ 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: From egadsby at towson.edu Mon Jan 23 15:28:03 2017 From: egadsby at towson.edu (Gadsby, Eric T.) Date: Mon, 23 Jan 2017 20:28:03 +0000 Subject: [Archivesspace_Users_Group] Best Practices For Updating from v1.5.1 to 1.5.2 - Redhat 7 Message-ID: <925926FF-29B7-446B-9157-293051226E7A@towson.edu> Dear Friends, Good afternoon. Later this week I will be updating our install of 1.5.1 to 1.5.2 other than the process laid out in the upgrading.md document have others found additional instructions or had any experience that make the process easier. Thanks! Eric T. Gadsby? IT Operations Specialist Cook Library Towson University ? 8000 York Road ? Towson, Maryland, 21252-0001 t. 410-704-3340 [cid:image001.png at 01D2758D.49275A40] [cid:image002.png at 01D2758D.49275A40] [cid:image003.png at 01D2758D.49275A40] [cid:image004.png at 01D2758D.49275A40] [cid:image005.gif at 01D2758D.49275A40] 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 Cook Library at 410-704-3340. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 479 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 591 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 546 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 622 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 1456 bytes Desc: image005.gif URL: From jazairi at bc.edu Mon Jan 23 16:33:16 2017 From: jazairi at bc.edu (Adam Jazairi) Date: Mon, 23 Jan 2017 16:33:16 -0500 Subject: [Archivesspace_Users_Group] Best Practices For Updating from v1.5.1 to 1.5.2 - Redhat 7 In-Reply-To: <925926FF-29B7-446B-9157-293051226E7A@towson.edu> References: <925926FF-29B7-446B-9157-293051226E7A@towson.edu> Message-ID: Hi Eric, We did this about a month ago and didn't run into any issues. If you're using MySQL, one thing to note is that the Sequel gem doesn't seem to recognize version 6.0.2 or higher of MySQL Connector. (We use 5.1.40.) I think this was also the case wither earlier versions, so you should be fine if you just copy the jar file from your previous install as suggested in upgrading.md. Happy upgrading! Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu On Mon, Jan 23, 2017 at 3:28 PM, Gadsby, Eric T. wrote: > Dear Friends, > > > > Good afternoon. Later this week I will be updating our install of 1.5.1 to > 1.5.2 other than the process laid out in the upgrading.md document have > others found additional instructions or had any experience that make the > process easier. Thanks! > > > > > > > > *Eric T. Gadsby*? *IT Operations Specialist* > > Cook Library > > Towson University ? 8000 York Road ? Towson, > Maryland, 21252-0001 > > t. 410-704-3340 <(410)%20704-3340> > > > > > > > > *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 Cook Library at 410-704-3340 <(410)%20704-3340>. > > > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 1456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 591 bytes Desc: not available URL: From james at hudmol.com Mon Jan 23 18:07:46 2017 From: james at hudmol.com (James Bullen) Date: Tue, 24 Jan 2017 10:07:46 +1100 Subject: [Archivesspace_Users_Group] Indexer erroring in 1.5.2 In-Reply-To: <1B0EA75C-EE19-492A-B057-FBAEFBBFB880@eservices.virginia.edu> References: <93c1c85c6385417d9e5ce9cbb3bc72bd@EX01.ads.nmu.edu> <8D4D67E1-FA36-4B3C-9699-E0575C013AF8@eservices.virginia.edu> <05AA6415-67E6-4D81-84BC-934AF6FC1E7A@hudmol.com> <86a66c023f6b4e338435bfe49c9a947d@EX01.ads.nmu.edu> <67CF95BC-356B-457D-9939-90A8EB0243A4@hudmol.com> <03C52CE3-AF95-4DCB-B680-6B08D1B249EB@eservices.virginia.edu> <1B0EA75C-EE19-492A-B057-FBAEFBBFB880@eservices.virginia.edu> Message-ID: Hi Steve, Yes that?s how it looks to me too. It should really be able to handle that case so I would consider this to be a bug. Cheers, James > On Jan 24, 2017, at 6:54 AM, Majewski, Steven Dennis (sdm7g) wrote: > > > 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) > wrote: >> >>> >>> On Jan 13, 2017, at 6:15 PM, James Bullen > 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 >> 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 >> 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 >> >> >> >> 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) > 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 > 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 > 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 ] On Behalf Of James Bullen >>>>>> Sent: Wednesday, January 11, 2017 6:56 PM >>>>>> To: Archivesspace Users Group > >>>>>> 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) > 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 > 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 >>>>>> 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 >>>>>> >>>>>> >>>>>> !DSPAM:587793334611909212977! >>>>> >>>>> _______________________________________________ >>>>> Archivesspace_Users_Group mailing list >>>>> 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 >>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>>> >>>> >>>> !DSPAM:587948af109451970717657! >>> >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> 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 >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > !DSPAM:58865fa6242613324871184! > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:58865fa6242613324871184! -------------- next part -------------- An HTML attachment was scrubbed... URL: From steelsen.smith at yale.edu Mon Jan 23 18:21:39 2017 From: steelsen.smith at yale.edu (Smith, Steelsen) Date: Mon, 23 Jan 2017 23:21:39 +0000 Subject: [Archivesspace_Users_Group] Modifying Search Results from API Message-ID: Hi All, I'm hoping someone has run into this before - I couldn't find anything in the list history. I'm working with the API and trying to get a list of top containers associated with a given series. Since top containers aren't easily linked from information in the tree or small_tree I'm using the search function to fetch a container based on either barcode or a combination of resource and series URIs. However, the search function returns massive amounts of data ( > 4mb for a large collection) which seems unnecessary. I tracked it down to the _resolved property in the linked_records property of the rights_restriction jsonmodel which is included in the active_restrictions property of the jsonmodel of the top container. It seems like there is way more information returned here then is every actually required from a search so I'm wondering if there's any way to change the properties returned by search endpoints without tweaking the jsonmodels or writing a plugin? Or to just return the URI in the ref property which seems to be the more typical behavior anyway? It seems like ASpace isn't totally consistent with returning recursive properties for every request (e.g., Children are not returned past one level in the tree when a node is provided despite being in the model) so I'm assuming that there's some flexibility here. Thanks in advance for any help, Steelsen ___________________________ Steelsen Smith Fulfillment Systems Specialist Enterprise Systems Group Yale Library IT 203.432.3333 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazairi at bc.edu Tue Jan 24 10:13:27 2017 From: jazairi at bc.edu (Adam Jazairi) Date: Tue, 24 Jan 2017 10:13:27 -0500 Subject: [Archivesspace_Users_Group] Cataloged note field Message-ID: Hello all, My institution is in the process of migrating from Archivists' Toolkit to ArchivesSpace, and we've noticed that the cataloged note field doesn't seem to map. This seems to be intentional, based on the discussion in the following ticket: https://archivesspace.atlassian.net/browse/AR-827 This is problematic for us because some of our records have important data in this field that we don't want to lose. Has anyone else encountered this issue? If so, I'd appreciate any advice on how to resolve it. For reference, we're running ArchivesSpace 1.5.2 and used the AT migration plugin to migrate our database. Thanks, Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From blparker at umd.edu Tue Jan 24 11:06:32 2017 From: blparker at umd.edu (Bria Lynn Parker) Date: Tue, 24 Jan 2017 11:06:32 -0500 Subject: [Archivesspace_Users_Group] EAD import error - indicator mismatch Message-ID: Hi all - I'm hoping someone has a tip or hint at where I'm going wrong: We've finished cleaning up/normalizing our EAD (including implementing container attributes and the like for container management). The majority are importing fine, no errors (or, at least no errors I can't find and fix, like bad begin/ends). However, for some of our finding aids, I'm getting the following: indicator_1 : Mismatch when mapping between indicator and indicator_1 No other info about location, etc. I've about torn my hair out trying to find *any* mismatch of container data - I've checked every instance's dummy barcode (which is constructed in part from the id), id, and parent against itself, crosschecked with the container indicator, and they all match within themselves. We're importing barcodes in the label attribute, which works (except when it doesn't here?). The error message getting thrown is from this ruby function https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/lib/aspace_json_to_managed_container_mapper.rb#L173 Help? If someone has encountered this and figured it out, let me know - I'd love some help. If you want to contact me off list, I can sent you a full xml file. Here's an example from my xml: Financial Records -- General -- Bound Volumes -- Financial Reports 1905-1908 1 1.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1909 1 2.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1910-1911 1 3.0 (historical background - some of our series restart box numbers at 1, and the container ids reflect that, so 89.1 is the 89th box in the collection, but 1st in the series. This is not causing the error as far as I can tell, since other collections with same numbering style import fine) -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From blparker at umd.edu Tue Jan 24 11:09:58 2017 From: blparker at umd.edu (Bria Lynn Parker) Date: Tue, 24 Jan 2017 11:09:58 -0500 Subject: [Archivesspace_Users_Group] EAD import error - indicator mismatch In-Reply-To: References: Message-ID: I should add: I'm running 1.5.2, and I have checked for sneaky whitespaces within any of these attributes and have found none. On Tue, Jan 24, 2017 at 11:06 AM, Bria Lynn Parker wrote: > Hi all - I'm hoping someone has a tip or hint at where I'm going wrong: > > We've finished cleaning up/normalizing our EAD (including implementing > container attributes and the like for container management). The majority > are importing fine, no errors (or, at least no errors I can't find and fix, > like bad begin/ends). However, for some of our finding aids, I'm getting > the following: > > indicator_1 : Mismatch when mapping between indicator and indicator_1 > > No other info about location, etc. I've about torn my hair out trying to > find *any* mismatch of container data - I've checked every instance's > dummy barcode (which is constructed in part from the id), id, and parent > against itself, crosschecked with the container indicator, and they all > match within themselves. We're importing barcodes in the label attribute, > which > works (except when it doesn't here?). The error message getting thrown is > from this ruby function https://github.com/archivesspace/archivesspace/ > blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/lib/ > aspace_json_to_managed_container_mapper.rb#L173 > > Help? If someone has encountered this and figured it out, let me know - > I'd love some help. If you want to contact me off list, I can sent you a > full xml file. > Here's an example from my xml: > > > > Financial Records -- General -- Bound Volumes -- > Financial Reports > 1905-1908 > "box" id="89.1">1 > 1.0 > > > > > > Financial Records -- General -- Bound Volumes -- > Financial Reports > 1909 > "box" id="89.1">1 > 2.0 > > > > > > > Financial Records -- General -- Bound Volumes -- > Financial Reports > 1910-1911 > "box" id="89.1">1 > 3.0 > > > > (historical background - some of our series restart box numbers at 1, and > the container ids reflect that, so 89.1 is the 89th box in the collection, > but 1st in the series. This is not causing the error as far as I can tell, > since other collections with same numbering style import fine) > > > -- > Bria L. Parker > Metadata Librarian > > 2200 McKeldin Library > > University of Maryland > > College Park, MD 20742-7011 > > (301) 405-9067 > > blparker at umd.edu > -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From PGalligan at rockarch.org Tue Jan 24 11:24:20 2017 From: PGalligan at rockarch.org (Galligan, Patrick) Date: Tue, 24 Jan 2017 16:24:20 +0000 Subject: [Archivesspace_Users_Group] EAD import error - indicator mismatch In-Reply-To: References: Message-ID: <6cab6b4d38c04631904dceb6c972ca9f@RACEX13.ad.rockarchive.org> Bria, I can?t tell you where exactly this is happening, but mismatch between indicators usually means that you have two different top container indicators assigned to the same barcode. You?d have to look at the barcodes that are already in the system, and any indicators associated with the import. I don?t see anything wrong in the snippet you sent below, but I also don?t really know what?s already in your database. We had a lot of these errors when we migrated to 1.5.0. -Patrick Galligan From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bria Lynn Parker Sent: Tuesday, January 24, 2017 11:10 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] EAD import error - indicator mismatch I should add: I'm running 1.5.2, and I have checked for sneaky whitespaces within any of these attributes and have found none. On Tue, Jan 24, 2017 at 11:06 AM, Bria Lynn Parker > wrote: Hi all - I'm hoping someone has a tip or hint at where I'm going wrong: We've finished cleaning up/normalizing our EAD (including implementing container attributes and the like for container management). The majority are importing fine, no errors (or, at least no errors I can't find and fix, like bad begin/ends). However, for some of our finding aids, I'm getting the following: indicator_1 : Mismatch when mapping between indicator and indicator_1 No other info about location, etc. I've about torn my hair out trying to find any mismatch of container data - I've checked every instance's dummy barcode (which is constructed in part from the id), id, and parent against itself, crosschecked with the container indicator, and they all match within themselves. We're importing barcodes in the label attribute, which works (except when it doesn't here?). The error message getting thrown is from this ruby function https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/lib/aspace_json_to_managed_container_mapper.rb#L173 Help? If someone has encountered this and figured it out, let me know - I'd love some help. If you want to contact me off list, I can sent you a full xml file. Here's an example from my xml: Financial Records -- General -- Bound Volumes -- Financial Reports 1905-1908 1 1.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1909 1 2.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1910-1911 1 3.0 (historical background - some of our series restart box numbers at 1, and the container ids reflect that, so 89.1 is the 89th box in the collection, but 1st in the series. This is not causing the error as far as I can tell, since other collections with same numbering style import fine) -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Tue Jan 24 11:24:32 2017 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 24 Jan 2017 16:24:32 +0000 Subject: [Archivesspace_Users_Group] EAD import error - indicator mismatch In-Reply-To: References: Message-ID: I was getting that error on 1.5.2 migration ( see other email thread ) and that one turned out to be due to an erroneous duplicate barcode assigned to different containers with different indicators. In the other cases, where there were trailing spaces in one of the barcodes, the message was a mismatch between barcode and barcode_1 ? the inverse error of the one above: same container, different barcodes. ? Steve. On Jan 24, 2017, at 11:10 AM, Bria Lynn Parker > wrote: I should add: I'm running 1.5.2, and I have checked for sneaky whitespaces within any of these attributes and have found none. On Tue, Jan 24, 2017 at 11:06 AM, Bria Lynn Parker > wrote: Hi all - I'm hoping someone has a tip or hint at where I'm going wrong: We've finished cleaning up/normalizing our EAD (including implementing container attributes and the like for container management). The majority are importing fine, no errors (or, at least no errors I can't find and fix, like bad begin/ends). However, for some of our finding aids, I'm getting the following: indicator_1 : Mismatch when mapping between indicator and indicator_1 No other info about location, etc. I've about torn my hair out trying to find any mismatch of container data - I've checked every instance's dummy barcode (which is constructed in part from the id), id, and parent against itself, crosschecked with the container indicator, and they all match within themselves. We're importing barcodes in the label attribute, which works (except when it doesn't here?). The error message getting thrown is from this ruby function https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/lib/aspace_json_to_managed_container_mapper.rb#L173 Help? If someone has encountered this and figured it out, let me know - I'd love some help. If you want to contact me off list, I can sent you a full xml file. Here's an example from my xml: Financial Records -- General -- Bound Volumes -- Financial Reports 1905-1908 1 1.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1909 1 2.0 Financial Records -- General -- Bound Volumes -- Financial Reports 1910-1911 1 3.0 (historical background - some of our series restart box numbers at 1, and the container ids reflect that, so 89.1 is the 89th box in the collection, but 1st in the series. This is not causing the error as far as I can tell, since other collections with same numbering style import fine) -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu _______________________________________________ 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: From jswierc1 at swarthmore.edu Tue Jan 24 12:57:41 2017 From: jswierc1 at swarthmore.edu (Julie Swierczek) Date: Tue, 24 Jan 2017 12:57:41 -0500 Subject: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person Message-ID: I have a large batch of MARCXML files to import. I keep getting error messages such as "Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction>". Is there some way to figure out which agent is causing the problem? The MARCXML record has thirty-three 700 fields, not to mention other agent fields, so using trial-and-error to find the problem is not a good use of time. I don't see any obvious problems, such as unusual characters in the fields. I have copied the agent fields and the complete error message below. Julie Agent fields: Committee on Militarism in Education (U.S.) Committee on Militarism in Education (U.S.) Archives. Sayre, John Nevin 1884-1977 Thomas, Norman 1884-1968 Wilson, E. Raymond Edward Raymond 1896-1987 Sayre, John Nevin 1884-1977 fast (OCoLC)fst00271556 Thomas, Norman 1884-1968 fast (OCoLC)fst00002998 Wilson, E. Raymond Edward Raymond 1896-1987 fast (OCoLC)fst00018322 Committee on Militarism in Education (U.S.) fast (OCoLC)fst00659515. United States. Army. Reserve Officers' Training Corps. fast (OCoLC)fst00541024. Barnes, Roswell P. Roswell Parkhurst 1901-1949 correspondent Allen, Devere 1891-1955 correspondent Armstrong, Eunice B. correspondent Atkinson, Henry A. correspondent Baldwin, Roger N. Roger Nash 1884-1981 correspondent Boss, Charles F. Charles Frederick 1888- correspondent Brinton, Ellen Starr 1886-1954 correspondent Bromley, Dorothy Dunbar 1896-1986 correspondent Catt, Carrie Chapman 1859-1947 correspondent Coe, George Albert 1862-1951 correspondent Detzer, Dorothy 1893-1981 correspondent Forbes, Rose Dabney 1864-1947 correspondent Johnson, Edwin C. correspondent Kirkpatrick, William 1757-1812 correspondent Lane, Winthrop D. Winthrop David 1887-1962 correspondent Libby, Frederick J. Frederick Joseph 1874-1970 correspondent Moore, Alfred S. correspondent Morgan, Laura Puffer 1874-1962 correspondent Newton, Ray correspondent Olmsted, Mildred Scott 1890-1990 correspondent Page, Kirby 1890-1957 correspondent Pharo, Florence M. correspondent Rankin, Jeannette 1880-1973 correspondent Sayre, John Nevin 1884-1977 correspondent Thomas, Norman 1884-1968 correspondent Tinker, Wellington H. correspondent Van Kirk, Walter W. Walter William 1891-1956 correspondent Villard, Oswald Garrison 1872-1949 correspondent Walser, Kenneth E. correspondent Wilson, E. Raymond Edward Raymond 1896-1987 correspondent Wilson, Theresa L. correspondent Wing, Andrew S. correspondent Wohlforth, Robert correspondent Error message: ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_caf81c0c-b6d7-48e0-8dcd-1811db9b9d5a Created: /subjects/import_71e38336-e415-41ad-9e24-94448bcb0174 Created: /subjects/import_af65aa65-3fb5-4db7-bae8-0d1e45a0a530 Created: /subjects/import_acbed94f-693a-4f58-bd5b-e978665f507a Created: /subjects/import_3b59252c-c5cd-4253-82c6-527ed678b298 Created: /subjects/import_cc64dc68-da3a-4b3d-b5d6-8165a0cea043 Created: /subjects/import_355b896a-57bc-4fec-9f91-860876e5081f Created: /subjects/import_b5e052fc-6e1f-4cc9-94d9-466ca6f850cb Created: /subjects/import_56488c97-6c0d-4440-ae36-0c51adb8308f Created: /subjects/import_14b8289b-4944-4d07-9b50-d49435f96451 Created: /subjects/import_4718b271-bac5-4e9a-b55b-ae1b57a93f1e Created: /subjects/import_307e05a7-6103-4c43-9697-cacb1cbae27e Created: /agents/corporate_entities/import_0c99d3d4-c545-4cf1-bddb-0aae8ebb4a3d Created: /agents/corporate_entities/import_1b627826-6122-4364-932b-e73bf94b5759 Created: /agents/corporate_entities/import_e7d1ae88-4f78-409e-843a-352957943012 Created: /agents/corporate_entities/import_93f40358-0e92-471e-adcc-37b8ee49ea47 Created: /agents/corporate_entities/import_1e514a27-8302-47ce-9e6a-11a8d7bd4caf Created: /agents/people/import_00a266ad-ad5e-40a7-8184-7411fe46c509 Created: /agents/people/import_08e4f942-9799-4aa3-989a-305d5b4ac4b9 Created: /agents/people/import_36ef683d-9478-4d94-a17f-75d6214defa6 Created: /agents/people/import_c1925b29-45e7-410c-9a8e-8333029364be Created: /agents/people/import_cd3f2e14-0e44-4e76-a026-54f16cb41f74 Created: /agents/people/import_6dd6cc26-bd13-4947-a3d4-677fedd2f809 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e5e28e11-92aa-4194-a7ee-f32535b96bf4 Created: /subjects/import_1788a8cc-65bb-4430-b738-5e98bbaf3666 Created: /subjects/import_ea42b8b2-5ebd-4697-b0a5-5690d8af6eee Created: /subjects/import_9e947cc6-07c2-4603-bc92-1293bd3223b6 Created: /subjects/import_b0526537-dfb4-4bdb-961f-2800a53d573b Created: /subjects/import_4b427bfb-a56d-4df0-8327-ffd93c7569d6 Created: /subjects/import_c99df3a7-959e-4b4f-b849-310e09657e10 Created: /subjects/import_8a2d3312-af21-4900-845a-6e510a5f6ee4 Created: /subjects/import_fd620c88-063f-4a89-8709-d0e26530ee1b Created: /subjects/import_52bb7bae-268b-41d5-aca1-d354f452a770 Created: /subjects/import_55a53bae-b69c-4020-a332-2efbc9656ef5 Created: /subjects/import_dc00c75e-ebfb-44a4-8de0-39f9f3b1042d Created: /agents/corporate_entities/import_5245f6ac-a3bf-46a2-aa70-c7baee0f6b02 Created: /agents/corporate_entities/import_25f258ee-7485-4abc-84a3-c4dd381ecf2f Created: /agents/corporate_entities/import_40b66820-036b-45d6-bb0d-1d968e8abb04 Created: /agents/corporate_entities/import_eba62ef9-e127-4882-a6f0-66645d3d4cbb Created: /agents/corporate_entities/import_f68c7e25-c650-458a-82d3-e98045da6026 Created: /agents/people/import_8934b302-68fa-4177-bd72-2ab28ec9798b Created: /agents/people/import_7d8a91df-b816-477b-99a8-348a3d0b288d Created: /agents/people/import_fddf487a-6748-4382-823f-fb9208d91fda Created: /agents/people/import_d25a9742-7008-4933-9f52-c09dd83282bb Created: /agents/people/import_e73f0812-d718-404c-b187-22df456af845 Created: /agents/people/import_4e157d1c-f328-42f9-a544-3653c783642b 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_99a75053-1563-41ec-91d1-16ad98ae117a Created: /subjects/import_b86a5572-4555-45df-8ff8-de96344281df Created: /subjects/import_7f2ce12c-27d5-431a-968b-b89911a1c8b7 Created: /subjects/import_cf05728f-15fe-49e1-9c6f-1638136cff3d Created: /subjects/import_2a06e540-cccf-4c06-adef-7236bf426b44 Created: /subjects/import_76cd94f2-750a-4cf2-a0a1-4b848b282f10 Created: /subjects/import_60c4837b-b94e-4bad-86fd-d4a91c1d0fd4 Created: /subjects/import_32b976f8-b533-407f-92fe-4b5551e7ee86 Created: /subjects/import_2efa9dbd-1181-46c1-b33a-d459d2b35729 Created: /subjects/import_e85bd8e4-6fb3-4259-967c-7fb45297919e Created: /subjects/import_d185ae21-4c29-4939-9158-3c1ffdb941ec Created: /subjects/import_876ca7e2-8c18-43b9-aae6-9d85b398e043 Created: /agents/corporate_entities/import_104cc59e-0d28-46b3-85f5-d83d6a6ac35c Created: /agents/corporate_entities/import_0ac902b8-0e7e-41fe-b0db-72f6e5078958 Created: /agents/corporate_entities/import_5f108b4d-a8cf-4d58-b40f-a0eeed583f4a Created: /agents/corporate_entities/import_e6401bfc-ce36-4990-906e-c0987cb9ec91 Created: /agents/corporate_entities/import_6aa2d667-ff88-455e-af44-d4ddc0786308 Created: /agents/people/import_34c29d35-def9-45ab-a685-d298820b6abd Created: /agents/people/import_1ceee9ff-2d6c-4b73-897f-28a37500339d Created: /agents/people/import_59afa168-0670-421c-9e4b-533d75042027 Created: /agents/people/import_d54d1d25-9686-427a-bd2a-a4273f4cff73 Created: /agents/people/import_47399d5c-cd27-4ff4-b18c-33e169d34356 Created: /agents/people/import_c462238f-66b6-47e6-b421-b470f11a0a01 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c3f64d7b-65a9-43c9-8f1c-954ef922b624 Created: /subjects/import_7c92cc3e-4f13-4423-84ff-6cc307c453f5 Created: /subjects/import_1f89b48c-2eaa-4a21-b084-3d2c61218322 Created: /subjects/import_e4688b9c-12aa-492d-80d4-88a7219a8238 Created: /subjects/import_856f6ba2-94b2-4acc-a5bb-4d487fc1ae6a Created: /subjects/import_ef67b8b5-b7e8-492e-9e9e-452afcf8ee1c Created: /subjects/import_cfbf17d9-a38e-4d30-8767-2fd501af733f Created: /subjects/import_72dc4155-ae9b-4eb2-af20-881af21a7249 Created: /subjects/import_5d6333eb-eac7-4bdd-98e5-842ead80bbd3 Created: /subjects/import_1dc55638-4797-4fb4-8a1d-e319b7d2ec65 Created: /subjects/import_f660f6e3-7561-4618-bf93-b4067637a0b2 Created: /subjects/import_b6160d40-88b2-44f1-882c-ad77600bd28e Created: /agents/corporate_entities/import_2f89c970-7c96-4308-aee9-ffc2e4ab9c89 Created: /agents/corporate_entities/import_9fa8c16e-1e56-43a0-b4d9-d9c29bd4a2b6 Created: /agents/corporate_entities/import_923e4698-4edf-442c-b8fe-58eb7ff3c326 Created: /agents/corporate_entities/import_a9eb9642-429f-40e6-9807-1f96f49c14fc Created: /agents/corporate_entities/import_525e06fb-4d46-4dde-bd27-00c7768429cb Created: /agents/people/import_af36d047-c8d9-484c-95c4-0de126f3a9e0 Created: /agents/people/import_4b43a3d0-b470-4edf-9bde-946e83e050d5 Created: /agents/people/import_46611bfa-59ac-414c-bbcf-924bd18881f7 Created: /agents/people/import_ecee7651-2f31-416c-bd6f-a68fc8d469e0 Created: /agents/people/import_dddc8645-8f26-4810-8138-326ac7e85799 Created: /agents/people/import_1712cee2-e832-4a9a-9bf0-de7469a3fed2 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c6ab2aae-9506-4a4b-b3e4-4dc7507e1fd4 Created: /subjects/import_1ba707a7-5320-415e-97c7-7bd4d9415506 Created: /subjects/import_eb763556-c61c-4c33-a347-15241622a1b2 Created: /subjects/import_5efb51a0-06a5-4768-8146-9547624ac6b3 Created: /subjects/import_73d7047d-8c21-4b79-ad20-53aff2c73ee5 Created: /subjects/import_86897835-e8e7-437b-bf24-9cad9ab2183a Created: /subjects/import_4fcedf51-6210-41ef-b175-7e94ec4941f8 Created: /subjects/import_c7ba965b-b72d-4b07-834f-e174d2718ed8 Created: /subjects/import_15008e65-9733-4735-8027-18a2e5b61edf Created: /subjects/import_31e3a9f2-1eb7-4273-8873-26f0f44303c2 Created: /subjects/import_b1b83b94-4ce8-4ea7-8c23-46e5575a041a Created: /subjects/import_29c0d0ed-efbe-41d7-b041-7d5cdb48a923 Created: /agents/corporate_entities/import_692c63a4-19d0-4946-a199-125d774c2e88 Created: /agents/corporate_entities/import_8236ca94-7cfd-4783-8979-4d3743fb46ba Created: /agents/corporate_entities/import_72516334-0834-43e3-8cf0-704493359de6 Created: /agents/corporate_entities/import_f21d0450-8a1c-4c1c-aaec-53a13c7ea5dd Created: /agents/corporate_entities/import_877420aa-63ef-4f5d-8504-7ac8e27968a6 Created: /agents/people/import_8bd6ff15-be5b-4891-8799-0d436c93a997 Created: /agents/people/import_522b9f78-92ae-4eb6-b8e1-3adeb595eed1 Created: /agents/people/import_280febc2-9095-4a96-b1af-f1ab97a5cd9d Created: /agents/people/import_bbf17ec9-010c-4d27-8651-4949f37fa7bc Created: /agents/people/import_fc0cb8b7-cb88-4384-b3a6-1d9229ca5925 Created: /agents/people/import_a617509c-e27e-4bbf-91c3-30c870999c82 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e2378314-3b96-467f-b1f0-c0d3e12df517 Created: /subjects/import_42ee60ae-f7fa-4b98-804b-ec8a56c1cb52 Created: /subjects/import_a719691b-1d2f-425d-a70e-a79d83878cd7 Created: /subjects/import_18578880-e8dc-47de-a722-f8687d9d1d2f Created: /subjects/import_6a7377f7-ffdd-4304-8288-ee6927f88d9c Created: /subjects/import_7acb72bf-3abd-4034-8c66-93596950e8e4 Created: /subjects/import_a1477324-3a2f-49e8-a69c-9915d686572b Created: /subjects/import_ffc27919-671f-43a0-953e-f7bb132cf93b Created: /subjects/import_bc16638d-8f55-4a79-bbca-53983365d046 Created: /subjects/import_ff5e71b6-94e0-411d-98b4-300f90536b44 Created: /subjects/import_d283411a-1885-4334-9e90-2b8e9e7a1799 Created: /subjects/import_dbb5a0df-fe9e-40fb-96a4-5c211c259739 Created: /agents/corporate_entities/import_ce5fd920-0de4-4133-a221-02fbbe64fb8d Created: /agents/corporate_entities/import_f8d8c117-9176-4f89-b841-3d6373542ecd Created: /agents/corporate_entities/import_79d839f7-e2d0-402c-94ca-11fcc0b40e4e Created: /agents/corporate_entities/import_245383e2-6e05-463e-9f2d-06881e7eb6bc Created: /agents/corporate_entities/import_8f243882-e530-408b-a8f0-0994e5e799b8 Created: /agents/people/import_a4ee33ab-0d92-4533-b368-d4c231949ea8 Created: /agents/people/import_3ee57000-af58-404b-a2f0-d4f0e3ef99c8 Created: /agents/people/import_9d3b3151-7eac-4e54-960c-3f183084dd85 Created: /agents/people/import_0965bf2a-0f88-42c8-916b-bb9245652b0a Created: /agents/people/import_e828f8e8-acb5-45f3-8b11-35086be50290 Created: /agents/people/import_53291093-e31b-4376-a251-62797b3c3d62 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c576523f-df9e-4ce5-b254-6935e7c63798 Created: /subjects/import_634080d9-64f8-445f-b1f7-b5b33e3d500f Created: /subjects/import_7fd209ee-a569-46ba-80ec-24107ac5e3cc Created: /subjects/import_9061d8e4-68ec-4e44-b37b-f498d82ef08f Created: /subjects/import_dacb34c3-a51e-40d4-8486-2be7f378dd90 Created: /subjects/import_20151084-6e94-4fae-aa49-00ca2164519f Created: /subjects/import_dd1c8212-26a3-4a74-8f7f-84abbdb74da6 Created: /subjects/import_0c488791-8dff-4b4d-acab-6201615de6fd Created: /subjects/import_85bec3c5-3218-4a41-aeb4-1ba2da8a1397 Created: /subjects/import_24ea01df-4b84-4305-b1e3-5b23c7c64c06 Created: /subjects/import_e561a8e4-ec64-416e-8089-edbb11617339 Created: /subjects/import_a835b0f6-6bb9-47de-9ce2-1fecabd2d39b Created: /agents/corporate_entities/import_522a656d-64f2-471c-969e-fa60c4c0369d Created: /agents/corporate_entities/import_324dfe69-9bd0-4697-98cb-f0b04f37ec28 Created: /agents/corporate_entities/import_24fd8520-1a2a-42f6-a6bb-f1ced4e2046d Created: /agents/corporate_entities/import_ffa3eab4-33bf-42e5-8242-92f14f3917d2 Created: /agents/corporate_entities/import_486e42bf-fc91-44ae-ad1e-666f73499549 Created: /agents/people/import_f1b2b641-43dc-4f0b-b11f-0ed61a57cbac Created: /agents/people/import_3c36e0dc-2fdd-4630-88a6-27d26fbc6374 Created: /agents/people/import_8e5225b2-9eda-45b3-b910-cc873cefc923 Created: /agents/people/import_1a297204-e285-41a1-8f34-722387cd0b99 Created: /agents/people/import_ba187ad3-fbac-43e3-9dd2-283c70b3a93f Created: /agents/people/import_1fb5859c-0131-45fc-b325-7d046ab78266 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_a12fdb96-767b-4d7f-9643-729010d4279a Created: /subjects/import_bdceefa1-d557-41e1-9394-a4fddd8146f1 Created: /subjects/import_1375d63f-31a0-4411-be8b-af4ec1735d7b Created: /subjects/import_9cda693f-d8d5-4b0f-9a9f-07980cd02378 Created: /subjects/import_7d17945c-6ee8-468f-be51-e9c2fcd48951 Created: /subjects/import_c7cc7048-c342-4034-91bb-817033141ed0 Created: /subjects/import_a2955899-3546-419b-8f67-411de3cbce3e Created: /subjects/import_ec37b2ae-72ec-45b7-8381-880672cb4c58 Created: /subjects/import_a69eb008-9cbe-4b24-9a70-cb6e8931b2ca Created: /subjects/import_76d74c50-2e37-4f11-9ee2-5e36643f699d Created: /subjects/import_06fceac1-2c14-4d7c-aad2-6e2cd5ec27fb Created: /subjects/import_b75357fc-94a7-40f3-828b-4ee46ea36e40 Created: /agents/corporate_entities/import_ba44d630-391e-4153-a0ce-543421b7cb50 Created: /agents/corporate_entities/import_7b2c0410-942c-4425-867d-3b4cd8fbeb45 Created: /agents/corporate_entities/import_74751112-da16-41ea-af3b-ca51b2af20a4 Created: /agents/corporate_entities/import_f1a50a2f-4b14-45db-93c8-636da87d1fc4 Created: /agents/corporate_entities/import_fb4693c8-5fd2-444d-9b19-e937538a6164 Created: /agents/people/import_b6b06dd9-a8fc-4d76-a1a6-c94bc423d584 Created: /agents/people/import_3e40eae4-47e0-41c0-9070-b6cf51666ae7 Created: /agents/people/import_a1796499-2819-42a2-96b7-2c8d37a17559 Created: /agents/people/import_f5c5bdc6-19a5-4e56-a996-8fa1171a70bc Created: /agents/people/import_e2390f91-db98-40fc-bad1-aaa59b1dbe2f Created: /agents/people/import_1bac4923-a6ab-4ce0-8262-f8ae3bbd9f9f 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_3419df18-66c1-4b50-84d6-18332ad12c01 Created: /subjects/import_bc25f42e-08f3-425e-990e-49432f1cd69c Created: /subjects/import_cf4a7610-9476-4d6e-a36b-c9d3fadf37d8 Created: /subjects/import_9fe3d9e6-fdd9-4a9b-9098-50c7627f3c48 Created: /subjects/import_59600c70-1d4c-4c0b-b3bb-30ae8df98f26 Created: /subjects/import_06b750e8-8631-471d-b9ba-999e7744626e Created: /subjects/import_1b59deb0-3ee4-4a8a-a131-fc2bd75a2630 Created: /subjects/import_5a5337c2-d8ca-438b-80b1-9dcfe7adbc93 Created: /subjects/import_81cb9d2a-fafc-4377-b748-88f69cd18f59 Created: /subjects/import_e77147c5-2e3b-422e-8fd4-26ea00f4af75 Created: /subjects/import_d7142cdf-1990-4058-b8cd-0370e94c4282 Created: /subjects/import_cf87aa36-2787-4912-b3db-586bb5393618 Created: /agents/corporate_entities/import_f38cd470-a9bf-43a4-87ad-b6f62bc24520 Created: /agents/corporate_entities/import_c76f10bf-5a8d-4166-868e-676547c07629 Created: /agents/corporate_entities/import_0e855bed-57be-48c6-9ee1-440b90f5912d Created: /agents/corporate_entities/import_88ed281b-7a01-4411-8f11-60b6b20085fd Created: /agents/corporate_entities/import_12b7df9f-f3ef-4610-bb65-8df72a1e5ff6 Created: /agents/people/import_641729ce-e12e-48f8-839e-ec1424824db9 Created: /agents/people/import_85a7c0c6-382c-4cfa-9b8f-53a7ad0f956d Created: /agents/people/import_418dd795-4585-43df-855a-0613f9876b35 Created: /agents/people/import_839e43eb-a5aa-4b91-bb5f-abe99e9fedbf Created: /agents/people/import_013a6de7-920b-48fe-906c-30ae132988a2 Created: /agents/people/import_6bf278bb-56ae-4c67-a71d-5048f01d6491 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_8b87f313-bcc8-4c31-9695-f4cc363048fc Created: /subjects/import_e2de5496-5b65-44ef-9834-51a094a5a291 Created: /subjects/import_f9bce3bc-eb55-49d6-bd4b-495789585e9a Created: /subjects/import_7d578521-36cc-4077-99ba-878c1be1d875 Created: /subjects/import_b02a1a65-316c-4ae4-b203-a4bb49ab1708 Created: /subjects/import_f450c4c9-3d4c-49c9-9643-49f5e40a0cec Created: /subjects/import_2e304ff5-d29b-4324-9a16-9ef1db9f8ccf Created: /subjects/import_9ac18ff1-081e-45bd-acc0-0c4f45fe02b3 Created: /subjects/import_a93deefd-121a-462a-bea7-62accb216f9e Created: /subjects/import_8ac56763-613f-4e5a-a106-5f8b46ea3e2b Created: /subjects/import_4e124c77-12f4-442c-a9b3-01431e5a573a Created: /subjects/import_154838cb-48b6-4c25-95d2-b5a5a7d9d929 Created: /agents/corporate_entities/import_2f59a661-f724-4a0a-bee5-ecef6e1d31b4 Created: /agents/corporate_entities/import_2f4636b9-f085-4a82-b7bd-ea401c433aa1 Created: /agents/corporate_entities/import_71963e39-5636-4eb0-8414-b224ee386d2a Created: /agents/corporate_entities/import_841224d6-0425-43e1-9b58-53bc86b86ba6 Created: /agents/corporate_entities/import_9a9028e1-36c9-4cec-9c0d-2a863644e5cc Created: /agents/people/import_926d153b-ee74-44d1-881b-0aeab8714bdd Created: /agents/people/import_47d59d8a-e3ad-4e36-a07e-4d55526b3b80 Created: /agents/people/import_b5850cb3-e5c9-4851-bd93-0a9e11e1c34f Created: /agents/people/import_74f33e8a-8608-4997-acec-6878a5a5ba78 Created: /agents/people/import_5a307b09-bd29-4583-8447-9b04a1252724 Created: /agents/people/import_95814b93-ef21-4343-8f63-47ec093dbadb 5. STARTED: Cleaning up 5. DONE: Cleaning up !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORT ERROR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah.huffman at duke.edu Tue Jan 24 14:47:01 2017 From: noah.huffman at duke.edu (Noah Huffman) Date: Tue, 24 Jan 2017 19:47:01 +0000 Subject: [Archivesspace_Users_Group] Cataloged note field In-Reply-To: References: Message-ID: Hi Adam, It?s recommended that you run the AT migration plugin to ArchivesSpace v.1.4.2 and then upgrade to ArchivesSpace to 1.5.2. Even so, I?m not clear on where the cataloged_note field maps. According to the AT migration mapping documentation, it should map to a collection management record, but I?m not seeing that field in collection management. As part of the 1.4.2 to 1.5.X upgrade, some collection management fields were converted to event records. You might check to see if any of your cataloged_note fields from AT now exist as event records in ArchivesSpace. I?m seeing some in my database, so I suspect that is what happened. -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982 http://library.duke.edu/rubenstein/ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Adam Jazairi Sent: Tuesday, January 24, 2017 10:13 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Cataloged note field Hello all, My institution is in the process of migrating from Archivists' Toolkit to ArchivesSpace, and we've noticed that the cataloged note field doesn't seem to map. This seems to be intentional, based on the discussion in the following ticket: https://archivesspace.atlassian.net/browse/AR-827 This is problematic for us because some of our records have important data in this field that we don't want to lose. Has anyone else encountered this issue? If so, I'd appreciate any advice on how to resolve it. For reference, we're running ArchivesSpace 1.5.2 and used the AT migration plugin to migrate our database. Thanks, Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazairi at bc.edu Tue Jan 24 15:23:50 2017 From: jazairi at bc.edu (Adam Jazairi) Date: Tue, 24 Jan 2017 15:23:50 -0500 Subject: [Archivesspace_Users_Group] Cataloged note field In-Reply-To: References: Message-ID: Hi Noah, Thanks for getting back to me. I should've clarified that though we're currently running 1.5.2, we used the plugin to migrate to 1.4.2 first. Sorry for any confusion. Our ArchivesSpace instance maps cataloged notes to events, but only partially. The events include the date accessioned and the linked record, but not the note itself. I wonder if this is an issue with the Archivists' Toolkit migration plugin. I'll have a look at the source code and see if anything looks awry. Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu On Tue, Jan 24, 2017 at 2:47 PM, Noah Huffman wrote: > Hi Adam, > > > > It?s recommended that you run the AT migration plugin to ArchivesSpace > v.1.4.2 and then upgrade to ArchivesSpace to 1.5.2. > > > > Even so, I?m not clear on where the cataloged_note field maps. According > to the AT migration mapping documentation > , > it should map to a collection management record, but I?m not seeing that > field in collection management. As part of the 1.4.2 to 1.5.X upgrade, > some collection management fields were converted to event records. You > might check to see if any of your cataloged_note fields from AT now exist > as event records in ArchivesSpace. I?m seeing some in my database, so I > suspect that is what happened. > > > > -Noah > > > > ================ > > Noah Huffman > > Archivist for Metadata, Systems, and Digital Records > > David M. Rubenstein Rare Book & Manuscript Library > > Duke University | 919-660-5982 <(919)%20660-5982> > > http://library.duke.edu/rubenstein/ > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Adam > Jazairi > *Sent:* Tuesday, January 24, 2017 10:13 AM > *To:* Archivesspace Users Group lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Cataloged note field > > > > Hello all, > > > > My institution is in the process of migrating from Archivists' Toolkit to > ArchivesSpace, and we've noticed that the cataloged note field doesn't seem > to map. This seems to be intentional, based on the discussion in the > following ticket: https://archivesspace.atlassian.net/browse/AR-827 > > > > > This is problematic for us because some of our records have important data > in this field that we don't want to lose. Has anyone else encountered this > issue? If so, I'd appreciate any advice on how to resolve it. > > > > For reference, we're running ArchivesSpace 1.5.2 and used the AT > migration plugin > > to migrate our database. > > > > Thanks, > > > > Adam > > > -- > > Adam Jazairi > > Digital Library Applications Developer > > Boston College Libraries > > (617) 552-1404 > > jazairi at bc.edu > > _______________________________________________ > 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: From jteitelbaum at pabmc.net Tue Jan 24 15:48:57 2017 From: jteitelbaum at pabmc.net (Teitelbaum, Jesse) Date: Tue, 24 Jan 2017 15:48:57 -0500 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating Message-ID: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the "sort title." For example, in ARCHON, the "Papers of John Doe" are listed under D for DOE, but when brought over to AS, all the collections beginning with "Papers of..." are listed under "P." Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah.huffman at duke.edu Tue Jan 24 15:57:20 2017 From: noah.huffman at duke.edu (Noah Huffman) Date: Tue, 24 Jan 2017 20:57:20 +0000 Subject: [Archivesspace_Users_Group] Cataloged note field In-Reply-To: References: Message-ID: Strange. My cataloged_note content from AT mapped to the Outcome Note field of the event record (see screenshot). But, I migrated from AT to an early version of ASpace (1.3?). I wonder if the mappings have changed since. Let me know what you discover. [cid:image002.jpg at 01D2765A.89DDBBB0] From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Adam Jazairi Sent: Tuesday, January 24, 2017 3:24 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Cataloged note field Hi Noah, Thanks for getting back to me. I should've clarified that though we're currently running 1.5.2, we used the plugin to migrate to 1.4.2 first. Sorry for any confusion. Our ArchivesSpace instance maps cataloged notes to events, but only partially. The events include the date accessioned and the linked record, but not the note itself. I wonder if this is an issue with the Archivists' Toolkit migration plugin. I'll have a look at the source code and see if anything looks awry. Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu On Tue, Jan 24, 2017 at 2:47 PM, Noah Huffman > wrote: Hi Adam, It?s recommended that you run the AT migration plugin to ArchivesSpace v.1.4.2 and then upgrade to ArchivesSpace to 1.5.2. Even so, I?m not clear on where the cataloged_note field maps. According to the AT migration mapping documentation, it should map to a collection management record, but I?m not seeing that field in collection management. As part of the 1.4.2 to 1.5.X upgrade, some collection management fields were converted to event records. You might check to see if any of your cataloged_note fields from AT now exist as event records in ArchivesSpace. I?m seeing some in my database, so I suspect that is what happened. -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982 http://library.duke.edu/rubenstein/ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Adam Jazairi Sent: Tuesday, January 24, 2017 10:13 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] Cataloged note field Hello all, My institution is in the process of migrating from Archivists' Toolkit to ArchivesSpace, and we've noticed that the cataloged note field doesn't seem to map. This seems to be intentional, based on the discussion in the following ticket: https://archivesspace.atlassian.net/browse/AR-827 This is problematic for us because some of our records have important data in this field that we don't want to lose. Has anyone else encountered this issue? If so, I'd appreciate any advice on how to resolve it. For reference, we're running ArchivesSpace 1.5.2 and used the AT migration plugin to migrate our database. Thanks, Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 22339 bytes Desc: image002.jpg URL: From prom at illinois.edu Tue Jan 24 16:23:06 2017 From: prom at illinois.edu (Prom, Christopher John) Date: Tue, 24 Jan 2017 21:23:06 +0000 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: References: Message-ID: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"?can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the ?sort title.? For example, in ARCHON, the ?Papers of John Doe? are listed under D for DOE, but when brought over to AS, all the collections beginning with ?Papers of?? are listed under ?P.? Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From lhocking at litchfieldhistoricalsociety.org Tue Jan 24 17:18:41 2017 From: lhocking at litchfieldhistoricalsociety.org (Linda Hocking) Date: Tue, 24 Jan 2017 22:18:41 +0000 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> References: , <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: Not sure if this helps to know, but we had the same issue. There is a field called "Finding Aid Filing Title" within the Finding Aid Data which seems to perform the same function, but the sort titles did not migrate to it. Linda Hocking Litchfield Historical Society ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Prom, Christopher John Sent: Tuesday, January 24, 2017 4:23:06 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"-can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the "sort title." For example, in ARCHON, the "Papers of John Doe" are listed under D for DOE, but when brought over to AS, all the collections beginning with "Papers of..." are listed under "P." Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From jsteele at jhu.edu Wed Jan 25 08:40:27 2017 From: jsteele at jhu.edu (Jordon Steele) Date: Wed, 25 Jan 2017 13:40:27 +0000 Subject: [Archivesspace_Users_Group] Many archives, one ASpace instance Message-ID: Hi, We have a few archival repositories in our institution's universe that are administratively separate. It's possible that in the future some of us will begin using a single instance of ASpace. I'm wondering if anyone who has experience building a successful partnership with multiple repositories using the same ASpace instance would be willing to speak with me about how you managed this cooperation and continue manage it. Feel free to message me off-list and we can set up a time to chat. Thanks! Best, Jordon Jordon Steele Hodson Curator of the University Archives The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jteitelbaum at pabmc.net Wed Jan 25 10:17:15 2017 From: jteitelbaum at pabmc.net (Teitelbaum, Jesse) Date: Wed, 25 Jan 2017 10:17:15 -0500 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: References: , <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: I don't see a "Finding Aid Filing Title" field in my data: [cid:image001.png at 01D276F4.33835AF0] And I did not create a user defined field for SORT TITLE at this point. It was a preliminary test. So is it safe to say a plug-in is necessary? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Linda Hocking Sent: Tuesday, January 24, 2017 5:19 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Not sure if this helps to know, but we had the same issue. There is a field called "Finding Aid Filing Title" within the Finding Aid Data which seems to perform the same function, but the sort titles did not migrate to it. Linda Hocking Litchfield Historical Society ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Prom, Christopher John > Sent: Tuesday, January 24, 2017 4:23:06 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"-can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the "sort title." For example, in ARCHON, the "Papers of John Doe" are listed under D for DOE, but when brought over to AS, all the collections beginning with "Papers of..." are listed under "P." Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 24619 bytes Desc: image001.png URL: From noah.huffman at duke.edu Wed Jan 25 10:44:29 2017 From: noah.huffman at duke.edu (Noah Huffman) Date: Wed, 25 Jan 2017 15:44:29 +0000 Subject: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person In-Reply-To: References: Message-ID: Hi Julie, I ran a test import of a MARC XML record that included the names you provide. I used the MarcXML (Resource) import type. I reproduced error you received. I tried reproducing the error with some of my own records and I think I found the culprit. There seems to be an odd bug in the MarcXML importer where the importer attempts to use the MARC 001 field in the bib record as the authority_id of each agent it creates from that MarcXML record. When there is more than one MARC 700 field in a single MarcXML record it results in duplicate authority_ids, which wrecks the import. When this happens, the import job seems to loop over the same record several times trying to create new agents until it finally throws the error you cited. As a workaround, you can just delete or comment out the MARC001 field in your import file. Here is the line in the importer code that seems to be the culprit: https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_base_map.rb#L292 I?m not sure why the importer is using the control number (Marc 001 field) from the bibliographic record as the authority_id of each agent. The control number identifies the bibliographic record, not the agent. That line should probably be removed from the import code. I?ve submitted a JIRA issue about this bug: https://archivesspace.atlassian.net/browse/AR-1643 I?m wondering if others have encountered this? -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Julie Swierczek Sent: Tuesday, January 24, 2017 12:58 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person I have a large batch of MARCXML files to import. I keep getting error messages such as "Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction>". Is there some way to figure out which agent is causing the problem? The MARCXML record has thirty-three 700 fields, not to mention other agent fields, so using trial-and-error to find the problem is not a good use of time. I don't see any obvious problems, such as unusual characters in the fields. I have copied the agent fields and the complete error message below. Julie Agent fields: Committee on Militarism in Education (U.S.) Committee on Militarism in Education (U.S.) Archives. Sayre, John Nevin 1884-1977 Thomas, Norman 1884-1968 Wilson, E. Raymond Edward Raymond 1896-1987 Sayre, John Nevin 1884-1977 fast (OCoLC)fst00271556 Thomas, Norman 1884-1968 fast (OCoLC)fst00002998 Wilson, E. Raymond Edward Raymond 1896-1987 fast (OCoLC)fst00018322 Committee on Militarism in Education (U.S.) fast (OCoLC)fst00659515. United States. Army. Reserve Officers' Training Corps. fast (OCoLC)fst00541024. Barnes, Roswell P. Roswell Parkhurst 1901-1949 correspondent Allen, Devere 1891-1955 correspondent Armstrong, Eunice B. correspondent Atkinson, Henry A. correspondent Baldwin, Roger N. Roger Nash 1884-1981 correspondent Boss, Charles F. Charles Frederick 1888- correspondent Brinton, Ellen Starr 1886-1954 correspondent Bromley, Dorothy Dunbar 1896-1986 correspondent Catt, Carrie Chapman 1859-1947 correspondent Coe, George Albert 1862-1951 correspondent Detzer, Dorothy 1893-1981 correspondent Forbes, Rose Dabney 1864-1947 correspondent Johnson, Edwin C. correspondent Kirkpatrick, William 1757-1812 correspondent Lane, Winthrop D. Winthrop David 1887-1962 correspondent Libby, Frederick J. Frederick Joseph 1874-1970 correspondent Moore, Alfred S. correspondent Morgan, Laura Puffer 1874-1962 correspondent Newton, Ray correspondent Olmsted, Mildred Scott 1890-1990 correspondent Page, Kirby 1890-1957 correspondent Pharo, Florence M. correspondent Rankin, Jeannette 1880-1973 correspondent Sayre, John Nevin 1884-1977 correspondent Thomas, Norman 1884-1968 correspondent Tinker, Wellington H. correspondent Van Kirk, Walter W. Walter William 1891-1956 correspondent Villard, Oswald Garrison 1872-1949 correspondent Walser, Kenneth E. correspondent Wilson, E. Raymond Edward Raymond 1896-1987 correspondent Wilson, Theresa L. correspondent Wing, Andrew S. correspondent Wohlforth, Robert correspondent Error message: ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_caf81c0c-b6d7-48e0-8dcd-1811db9b9d5a Created: /subjects/import_71e38336-e415-41ad-9e24-94448bcb0174 Created: /subjects/import_af65aa65-3fb5-4db7-bae8-0d1e45a0a530 Created: /subjects/import_acbed94f-693a-4f58-bd5b-e978665f507a Created: /subjects/import_3b59252c-c5cd-4253-82c6-527ed678b298 Created: /subjects/import_cc64dc68-da3a-4b3d-b5d6-8165a0cea043 Created: /subjects/import_355b896a-57bc-4fec-9f91-860876e5081f Created: /subjects/import_b5e052fc-6e1f-4cc9-94d9-466ca6f850cb Created: /subjects/import_56488c97-6c0d-4440-ae36-0c51adb8308f Created: /subjects/import_14b8289b-4944-4d07-9b50-d49435f96451 Created: /subjects/import_4718b271-bac5-4e9a-b55b-ae1b57a93f1e Created: /subjects/import_307e05a7-6103-4c43-9697-cacb1cbae27e Created: /agents/corporate_entities/import_0c99d3d4-c545-4cf1-bddb-0aae8ebb4a3d Created: /agents/corporate_entities/import_1b627826-6122-4364-932b-e73bf94b5759 Created: /agents/corporate_entities/import_e7d1ae88-4f78-409e-843a-352957943012 Created: /agents/corporate_entities/import_93f40358-0e92-471e-adcc-37b8ee49ea47 Created: /agents/corporate_entities/import_1e514a27-8302-47ce-9e6a-11a8d7bd4caf Created: /agents/people/import_00a266ad-ad5e-40a7-8184-7411fe46c509 Created: /agents/people/import_08e4f942-9799-4aa3-989a-305d5b4ac4b9 Created: /agents/people/import_36ef683d-9478-4d94-a17f-75d6214defa6 Created: /agents/people/import_c1925b29-45e7-410c-9a8e-8333029364be Created: /agents/people/import_cd3f2e14-0e44-4e76-a026-54f16cb41f74 Created: /agents/people/import_6dd6cc26-bd13-4947-a3d4-677fedd2f809 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e5e28e11-92aa-4194-a7ee-f32535b96bf4 Created: /subjects/import_1788a8cc-65bb-4430-b738-5e98bbaf3666 Created: /subjects/import_ea42b8b2-5ebd-4697-b0a5-5690d8af6eee Created: /subjects/import_9e947cc6-07c2-4603-bc92-1293bd3223b6 Created: /subjects/import_b0526537-dfb4-4bdb-961f-2800a53d573b Created: /subjects/import_4b427bfb-a56d-4df0-8327-ffd93c7569d6 Created: /subjects/import_c99df3a7-959e-4b4f-b849-310e09657e10 Created: /subjects/import_8a2d3312-af21-4900-845a-6e510a5f6ee4 Created: /subjects/import_fd620c88-063f-4a89-8709-d0e26530ee1b Created: /subjects/import_52bb7bae-268b-41d5-aca1-d354f452a770 Created: /subjects/import_55a53bae-b69c-4020-a332-2efbc9656ef5 Created: /subjects/import_dc00c75e-ebfb-44a4-8de0-39f9f3b1042d Created: /agents/corporate_entities/import_5245f6ac-a3bf-46a2-aa70-c7baee0f6b02 Created: /agents/corporate_entities/import_25f258ee-7485-4abc-84a3-c4dd381ecf2f Created: /agents/corporate_entities/import_40b66820-036b-45d6-bb0d-1d968e8abb04 Created: /agents/corporate_entities/import_eba62ef9-e127-4882-a6f0-66645d3d4cbb Created: /agents/corporate_entities/import_f68c7e25-c650-458a-82d3-e98045da6026 Created: /agents/people/import_8934b302-68fa-4177-bd72-2ab28ec9798b Created: /agents/people/import_7d8a91df-b816-477b-99a8-348a3d0b288d Created: /agents/people/import_fddf487a-6748-4382-823f-fb9208d91fda Created: /agents/people/import_d25a9742-7008-4933-9f52-c09dd83282bb Created: /agents/people/import_e73f0812-d718-404c-b187-22df456af845 Created: /agents/people/import_4e157d1c-f328-42f9-a544-3653c783642b 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_99a75053-1563-41ec-91d1-16ad98ae117a Created: /subjects/import_b86a5572-4555-45df-8ff8-de96344281df Created: /subjects/import_7f2ce12c-27d5-431a-968b-b89911a1c8b7 Created: /subjects/import_cf05728f-15fe-49e1-9c6f-1638136cff3d Created: /subjects/import_2a06e540-cccf-4c06-adef-7236bf426b44 Created: /subjects/import_76cd94f2-750a-4cf2-a0a1-4b848b282f10 Created: /subjects/import_60c4837b-b94e-4bad-86fd-d4a91c1d0fd4 Created: /subjects/import_32b976f8-b533-407f-92fe-4b5551e7ee86 Created: /subjects/import_2efa9dbd-1181-46c1-b33a-d459d2b35729 Created: /subjects/import_e85bd8e4-6fb3-4259-967c-7fb45297919e Created: /subjects/import_d185ae21-4c29-4939-9158-3c1ffdb941ec Created: /subjects/import_876ca7e2-8c18-43b9-aae6-9d85b398e043 Created: /agents/corporate_entities/import_104cc59e-0d28-46b3-85f5-d83d6a6ac35c Created: /agents/corporate_entities/import_0ac902b8-0e7e-41fe-b0db-72f6e5078958 Created: /agents/corporate_entities/import_5f108b4d-a8cf-4d58-b40f-a0eeed583f4a Created: /agents/corporate_entities/import_e6401bfc-ce36-4990-906e-c0987cb9ec91 Created: /agents/corporate_entities/import_6aa2d667-ff88-455e-af44-d4ddc0786308 Created: /agents/people/import_34c29d35-def9-45ab-a685-d298820b6abd Created: /agents/people/import_1ceee9ff-2d6c-4b73-897f-28a37500339d Created: /agents/people/import_59afa168-0670-421c-9e4b-533d75042027 Created: /agents/people/import_d54d1d25-9686-427a-bd2a-a4273f4cff73 Created: /agents/people/import_47399d5c-cd27-4ff4-b18c-33e169d34356 Created: /agents/people/import_c462238f-66b6-47e6-b421-b470f11a0a01 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c3f64d7b-65a9-43c9-8f1c-954ef922b624 Created: /subjects/import_7c92cc3e-4f13-4423-84ff-6cc307c453f5 Created: /subjects/import_1f89b48c-2eaa-4a21-b084-3d2c61218322 Created: /subjects/import_e4688b9c-12aa-492d-80d4-88a7219a8238 Created: /subjects/import_856f6ba2-94b2-4acc-a5bb-4d487fc1ae6a Created: /subjects/import_ef67b8b5-b7e8-492e-9e9e-452afcf8ee1c Created: /subjects/import_cfbf17d9-a38e-4d30-8767-2fd501af733f Created: /subjects/import_72dc4155-ae9b-4eb2-af20-881af21a7249 Created: /subjects/import_5d6333eb-eac7-4bdd-98e5-842ead80bbd3 Created: /subjects/import_1dc55638-4797-4fb4-8a1d-e319b7d2ec65 Created: /subjects/import_f660f6e3-7561-4618-bf93-b4067637a0b2 Created: /subjects/import_b6160d40-88b2-44f1-882c-ad77600bd28e Created: /agents/corporate_entities/import_2f89c970-7c96-4308-aee9-ffc2e4ab9c89 Created: /agents/corporate_entities/import_9fa8c16e-1e56-43a0-b4d9-d9c29bd4a2b6 Created: /agents/corporate_entities/import_923e4698-4edf-442c-b8fe-58eb7ff3c326 Created: /agents/corporate_entities/import_a9eb9642-429f-40e6-9807-1f96f49c14fc Created: /agents/corporate_entities/import_525e06fb-4d46-4dde-bd27-00c7768429cb Created: /agents/people/import_af36d047-c8d9-484c-95c4-0de126f3a9e0 Created: /agents/people/import_4b43a3d0-b470-4edf-9bde-946e83e050d5 Created: /agents/people/import_46611bfa-59ac-414c-bbcf-924bd18881f7 Created: /agents/people/import_ecee7651-2f31-416c-bd6f-a68fc8d469e0 Created: /agents/people/import_dddc8645-8f26-4810-8138-326ac7e85799 Created: /agents/people/import_1712cee2-e832-4a9a-9bf0-de7469a3fed2 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c6ab2aae-9506-4a4b-b3e4-4dc7507e1fd4 Created: /subjects/import_1ba707a7-5320-415e-97c7-7bd4d9415506 Created: /subjects/import_eb763556-c61c-4c33-a347-15241622a1b2 Created: /subjects/import_5efb51a0-06a5-4768-8146-9547624ac6b3 Created: /subjects/import_73d7047d-8c21-4b79-ad20-53aff2c73ee5 Created: /subjects/import_86897835-e8e7-437b-bf24-9cad9ab2183a Created: /subjects/import_4fcedf51-6210-41ef-b175-7e94ec4941f8 Created: /subjects/import_c7ba965b-b72d-4b07-834f-e174d2718ed8 Created: /subjects/import_15008e65-9733-4735-8027-18a2e5b61edf Created: /subjects/import_31e3a9f2-1eb7-4273-8873-26f0f44303c2 Created: /subjects/import_b1b83b94-4ce8-4ea7-8c23-46e5575a041a Created: /subjects/import_29c0d0ed-efbe-41d7-b041-7d5cdb48a923 Created: /agents/corporate_entities/import_692c63a4-19d0-4946-a199-125d774c2e88 Created: /agents/corporate_entities/import_8236ca94-7cfd-4783-8979-4d3743fb46ba Created: /agents/corporate_entities/import_72516334-0834-43e3-8cf0-704493359de6 Created: /agents/corporate_entities/import_f21d0450-8a1c-4c1c-aaec-53a13c7ea5dd Created: /agents/corporate_entities/import_877420aa-63ef-4f5d-8504-7ac8e27968a6 Created: /agents/people/import_8bd6ff15-be5b-4891-8799-0d436c93a997 Created: /agents/people/import_522b9f78-92ae-4eb6-b8e1-3adeb595eed1 Created: /agents/people/import_280febc2-9095-4a96-b1af-f1ab97a5cd9d Created: /agents/people/import_bbf17ec9-010c-4d27-8651-4949f37fa7bc Created: /agents/people/import_fc0cb8b7-cb88-4384-b3a6-1d9229ca5925 Created: /agents/people/import_a617509c-e27e-4bbf-91c3-30c870999c82 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e2378314-3b96-467f-b1f0-c0d3e12df517 Created: /subjects/import_42ee60ae-f7fa-4b98-804b-ec8a56c1cb52 Created: /subjects/import_a719691b-1d2f-425d-a70e-a79d83878cd7 Created: /subjects/import_18578880-e8dc-47de-a722-f8687d9d1d2f Created: /subjects/import_6a7377f7-ffdd-4304-8288-ee6927f88d9c Created: /subjects/import_7acb72bf-3abd-4034-8c66-93596950e8e4 Created: /subjects/import_a1477324-3a2f-49e8-a69c-9915d686572b Created: /subjects/import_ffc27919-671f-43a0-953e-f7bb132cf93b Created: /subjects/import_bc16638d-8f55-4a79-bbca-53983365d046 Created: /subjects/import_ff5e71b6-94e0-411d-98b4-300f90536b44 Created: /subjects/import_d283411a-1885-4334-9e90-2b8e9e7a1799 Created: /subjects/import_dbb5a0df-fe9e-40fb-96a4-5c211c259739 Created: /agents/corporate_entities/import_ce5fd920-0de4-4133-a221-02fbbe64fb8d Created: /agents/corporate_entities/import_f8d8c117-9176-4f89-b841-3d6373542ecd Created: /agents/corporate_entities/import_79d839f7-e2d0-402c-94ca-11fcc0b40e4e Created: /agents/corporate_entities/import_245383e2-6e05-463e-9f2d-06881e7eb6bc Created: /agents/corporate_entities/import_8f243882-e530-408b-a8f0-0994e5e799b8 Created: /agents/people/import_a4ee33ab-0d92-4533-b368-d4c231949ea8 Created: /agents/people/import_3ee57000-af58-404b-a2f0-d4f0e3ef99c8 Created: /agents/people/import_9d3b3151-7eac-4e54-960c-3f183084dd85 Created: /agents/people/import_0965bf2a-0f88-42c8-916b-bb9245652b0a Created: /agents/people/import_e828f8e8-acb5-45f3-8b11-35086be50290 Created: /agents/people/import_53291093-e31b-4376-a251-62797b3c3d62 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c576523f-df9e-4ce5-b254-6935e7c63798 Created: /subjects/import_634080d9-64f8-445f-b1f7-b5b33e3d500f Created: /subjects/import_7fd209ee-a569-46ba-80ec-24107ac5e3cc Created: /subjects/import_9061d8e4-68ec-4e44-b37b-f498d82ef08f Created: /subjects/import_dacb34c3-a51e-40d4-8486-2be7f378dd90 Created: /subjects/import_20151084-6e94-4fae-aa49-00ca2164519f Created: /subjects/import_dd1c8212-26a3-4a74-8f7f-84abbdb74da6 Created: /subjects/import_0c488791-8dff-4b4d-acab-6201615de6fd Created: /subjects/import_85bec3c5-3218-4a41-aeb4-1ba2da8a1397 Created: /subjects/import_24ea01df-4b84-4305-b1e3-5b23c7c64c06 Created: /subjects/import_e561a8e4-ec64-416e-8089-edbb11617339 Created: /subjects/import_a835b0f6-6bb9-47de-9ce2-1fecabd2d39b Created: /agents/corporate_entities/import_522a656d-64f2-471c-969e-fa60c4c0369d Created: /agents/corporate_entities/import_324dfe69-9bd0-4697-98cb-f0b04f37ec28 Created: /agents/corporate_entities/import_24fd8520-1a2a-42f6-a6bb-f1ced4e2046d Created: /agents/corporate_entities/import_ffa3eab4-33bf-42e5-8242-92f14f3917d2 Created: /agents/corporate_entities/import_486e42bf-fc91-44ae-ad1e-666f73499549 Created: /agents/people/import_f1b2b641-43dc-4f0b-b11f-0ed61a57cbac Created: /agents/people/import_3c36e0dc-2fdd-4630-88a6-27d26fbc6374 Created: /agents/people/import_8e5225b2-9eda-45b3-b910-cc873cefc923 Created: /agents/people/import_1a297204-e285-41a1-8f34-722387cd0b99 Created: /agents/people/import_ba187ad3-fbac-43e3-9dd2-283c70b3a93f Created: /agents/people/import_1fb5859c-0131-45fc-b325-7d046ab78266 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_a12fdb96-767b-4d7f-9643-729010d4279a Created: /subjects/import_bdceefa1-d557-41e1-9394-a4fddd8146f1 Created: /subjects/import_1375d63f-31a0-4411-be8b-af4ec1735d7b Created: /subjects/import_9cda693f-d8d5-4b0f-9a9f-07980cd02378 Created: /subjects/import_7d17945c-6ee8-468f-be51-e9c2fcd48951 Created: /subjects/import_c7cc7048-c342-4034-91bb-817033141ed0 Created: /subjects/import_a2955899-3546-419b-8f67-411de3cbce3e Created: /subjects/import_ec37b2ae-72ec-45b7-8381-880672cb4c58 Created: /subjects/import_a69eb008-9cbe-4b24-9a70-cb6e8931b2ca Created: /subjects/import_76d74c50-2e37-4f11-9ee2-5e36643f699d Created: /subjects/import_06fceac1-2c14-4d7c-aad2-6e2cd5ec27fb Created: /subjects/import_b75357fc-94a7-40f3-828b-4ee46ea36e40 Created: /agents/corporate_entities/import_ba44d630-391e-4153-a0ce-543421b7cb50 Created: /agents/corporate_entities/import_7b2c0410-942c-4425-867d-3b4cd8fbeb45 Created: /agents/corporate_entities/import_74751112-da16-41ea-af3b-ca51b2af20a4 Created: /agents/corporate_entities/import_f1a50a2f-4b14-45db-93c8-636da87d1fc4 Created: /agents/corporate_entities/import_fb4693c8-5fd2-444d-9b19-e937538a6164 Created: /agents/people/import_b6b06dd9-a8fc-4d76-a1a6-c94bc423d584 Created: /agents/people/import_3e40eae4-47e0-41c0-9070-b6cf51666ae7 Created: /agents/people/import_a1796499-2819-42a2-96b7-2c8d37a17559 Created: /agents/people/import_f5c5bdc6-19a5-4e56-a996-8fa1171a70bc Created: /agents/people/import_e2390f91-db98-40fc-bad1-aaa59b1dbe2f Created: /agents/people/import_1bac4923-a6ab-4ce0-8262-f8ae3bbd9f9f 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_3419df18-66c1-4b50-84d6-18332ad12c01 Created: /subjects/import_bc25f42e-08f3-425e-990e-49432f1cd69c Created: /subjects/import_cf4a7610-9476-4d6e-a36b-c9d3fadf37d8 Created: /subjects/import_9fe3d9e6-fdd9-4a9b-9098-50c7627f3c48 Created: /subjects/import_59600c70-1d4c-4c0b-b3bb-30ae8df98f26 Created: /subjects/import_06b750e8-8631-471d-b9ba-999e7744626e Created: /subjects/import_1b59deb0-3ee4-4a8a-a131-fc2bd75a2630 Created: /subjects/import_5a5337c2-d8ca-438b-80b1-9dcfe7adbc93 Created: /subjects/import_81cb9d2a-fafc-4377-b748-88f69cd18f59 Created: /subjects/import_e77147c5-2e3b-422e-8fd4-26ea00f4af75 Created: /subjects/import_d7142cdf-1990-4058-b8cd-0370e94c4282 Created: /subjects/import_cf87aa36-2787-4912-b3db-586bb5393618 Created: /agents/corporate_entities/import_f38cd470-a9bf-43a4-87ad-b6f62bc24520 Created: /agents/corporate_entities/import_c76f10bf-5a8d-4166-868e-676547c07629 Created: /agents/corporate_entities/import_0e855bed-57be-48c6-9ee1-440b90f5912d Created: /agents/corporate_entities/import_88ed281b-7a01-4411-8f11-60b6b20085fd Created: /agents/corporate_entities/import_12b7df9f-f3ef-4610-bb65-8df72a1e5ff6 Created: /agents/people/import_641729ce-e12e-48f8-839e-ec1424824db9 Created: /agents/people/import_85a7c0c6-382c-4cfa-9b8f-53a7ad0f956d Created: /agents/people/import_418dd795-4585-43df-855a-0613f9876b35 Created: /agents/people/import_839e43eb-a5aa-4b91-bb5f-abe99e9fedbf Created: /agents/people/import_013a6de7-920b-48fe-906c-30ae132988a2 Created: /agents/people/import_6bf278bb-56ae-4c67-a71d-5048f01d6491 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_8b87f313-bcc8-4c31-9695-f4cc363048fc Created: /subjects/import_e2de5496-5b65-44ef-9834-51a094a5a291 Created: /subjects/import_f9bce3bc-eb55-49d6-bd4b-495789585e9a Created: /subjects/import_7d578521-36cc-4077-99ba-878c1be1d875 Created: /subjects/import_b02a1a65-316c-4ae4-b203-a4bb49ab1708 Created: /subjects/import_f450c4c9-3d4c-49c9-9643-49f5e40a0cec Created: /subjects/import_2e304ff5-d29b-4324-9a16-9ef1db9f8ccf Created: /subjects/import_9ac18ff1-081e-45bd-acc0-0c4f45fe02b3 Created: /subjects/import_a93deefd-121a-462a-bea7-62accb216f9e Created: /subjects/import_8ac56763-613f-4e5a-a106-5f8b46ea3e2b Created: /subjects/import_4e124c77-12f4-442c-a9b3-01431e5a573a Created: /subjects/import_154838cb-48b6-4c25-95d2-b5a5a7d9d929 Created: /agents/corporate_entities/import_2f59a661-f724-4a0a-bee5-ecef6e1d31b4 Created: /agents/corporate_entities/import_2f4636b9-f085-4a82-b7bd-ea401c433aa1 Created: /agents/corporate_entities/import_71963e39-5636-4eb0-8414-b224ee386d2a Created: /agents/corporate_entities/import_841224d6-0425-43e1-9b58-53bc86b86ba6 Created: /agents/corporate_entities/import_9a9028e1-36c9-4cec-9c0d-2a863644e5cc Created: /agents/people/import_926d153b-ee74-44d1-881b-0aeab8714bdd Created: /agents/people/import_47d59d8a-e3ad-4e36-a07e-4d55526b3b80 Created: /agents/people/import_b5850cb3-e5c9-4851-bd93-0a9e11e1c34f Created: /agents/people/import_74f33e8a-8608-4997-acec-6878a5a5ba78 Created: /agents/people/import_5a307b09-bd29-4583-8447-9b04a1252724 Created: /agents/people/import_95814b93-ef21-4343-8f63-47ec093dbadb 5. STARTED: Cleaning up 5. DONE: Cleaning up !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORT ERROR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kate_bowers at harvard.edu Wed Jan 25 11:34:55 2017 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Wed, 25 Jan 2017 16:34:55 +0000 Subject: [Archivesspace_Users_Group] Ingesting lcnaf Message-ID: Searching list archives and google, I understand someone has written a plugin that ingests LCNAF. Can anyone point me to documentation of what this plugin is meant to do? If you use it, I'd appreciate any documentation you have written or reviews of your experiences with it? Screenshots of agent records post-ingest would be extremely helpful. Thanks! Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu voice: (617) 998-5238 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Heather.Klish at tufts.edu Wed Jan 25 11:37:39 2017 From: Heather.Klish at tufts.edu (Klish, Heather J) Date: Wed, 25 Jan 2017 16:37:39 +0000 Subject: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list Message-ID: <70BEEB1EDDA0CF458519422A45AEF5D6E9037532@tabvmexdag1mb03.tufts.ad.tufts.edu> Hi everyone, We have two repositories on our production server - our original repository that we've been using for a while and one that we've just created. When we click on the 'Manage Repositories' link, we only see the new repository in the list. We've replicated the new repository on a test server and on that server, we can see both repositories in the list. Can anyone help with why we can't see both repositories on our production server? Thanks! Heather . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heather Klish | Systems Librarian TTS : Library Technology Services Tufts University heather.klish at tufts.edu | 617.627.5853 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkottman at ku.edu Wed Jan 25 12:52:53 2017 From: mkottman at ku.edu (Kottman, Miloche) Date: Wed, 25 Jan 2017 17:52:53 +0000 Subject: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list In-Reply-To: <70BEEB1EDDA0CF458519422A45AEF5D6E9037532@tabvmexdag1mb03.tufts.ad.tufts.edu> References: <70BEEB1EDDA0CF458519422A45AEF5D6E9037532@tabvmexdag1mb03.tufts.ad.tufts.edu> Message-ID: <12fad1abbb024e9991d3d1e0e457fb4d@ex13-ell-cr-15.home.ku.edu> I would double-check the access/permissions. If you are logged in as a system administrator then you should be able to see all the repositories. Anyone else would need to have their permissions set up for each repository by having a system administrator open the "missing" repository and adding individual users to appropriate groups via the Manage Groups function. --Miloche Miloche Kottman Head of Cataloging and Archival Processing University of Kansas Libraries Lawrence, KS 66045 mkottman at ku.edu 785-864-3916 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Klish, Heather J Sent: Wednesday, January 25, 2017 10:38 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list Hi everyone, We have two repositories on our production server - our original repository that we've been using for a while and one that we've just created. When we click on the 'Manage Repositories' link, we only see the new repository in the list. We've replicated the new repository on a test server and on that server, we can see both repositories in the list. Can anyone help with why we can't see both repositories on our production server? Thanks! Heather . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heather Klish | Systems Librarian TTS : Library Technology Services Tufts University heather.klish at tufts.edu | 617.627.5853 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blparker at umd.edu Wed Jan 25 13:11:02 2017 From: blparker at umd.edu (Bria Lynn Parker) Date: Wed, 25 Jan 2017 13:11:02 -0500 Subject: [Archivesspace_Users_Group] EAD import error - indicator mismatch In-Reply-To: References: Message-ID: Well, so it turns out the issue wasn't so much with my data, but that I did not realize that deleting a resource does not also delete the top containers created when importing a resource and associated with that resource. So my own testing was my downfall! Thankfully this was all on a test server, so I could easily purge all the old top containers... Thanks all for the guidance, though! On Tue, Jan 24, 2017 at 11:24 AM, Majewski, Steven Dennis (sdm7g) < sdm7g at eservices.virginia.edu> wrote: > > I was getting that error on 1.5.2 migration ( see other email thread ) and > that one turned out to be due to an erroneous duplicate barcode assigned > to different containers with different indicators. > > In the other cases, where there were trailing spaces in one of the > barcodes, the message was a mismatch between barcode and barcode_1 ? the > inverse error of the one above: same container, different barcodes. > > ? Steve. > > > > On Jan 24, 2017, at 11:10 AM, Bria Lynn Parker wrote: > > I should add: > > I'm running 1.5.2, and I have checked for sneaky whitespaces within any of > these attributes and have found none. > > On Tue, Jan 24, 2017 at 11:06 AM, Bria Lynn Parker wrot > e: > >> Hi all - I'm hoping someone has a tip or hint at where I'm going wrong: >> >> We've finished cleaning up/normalizing our EAD (including implementing >> container attributes and the like for container management). The majority >> are importing fine, no errors (or, at least no errors I can't find and fix, >> like bad begin/ends). However, for some of our finding aids, I'm getting >> the following: >> >> indicator_1 : Mismatch when mapping between indicator and indicator_1 >> >> No other info about location, etc. I've about torn my hair out trying to >> find *any* mismatch of container data - I've checked every instance's >> dummy barcode (which is constructed in part from the id), id, and parent >> against itself, crosschecked with the container indicator, and they all >> match within themselves. We're importing barcodes in the label attribute, >> which >> works (except when it doesn't here?). The error message getting thrown is >> from this ruby function https://github.com/archivesspa >> ce/archivesspace/blob/5e1ca66f1f04f142f2695024efb72008250463 >> 25/backend/app/lib/aspace_json_to_managed_container_mapper.rb#L173 >> >> Help? If someone has encountered this and figured it out, let me know - >> I'd love some help. If you want to contact me off list, I can sent you a >> full xml file. >> Here's an example from my xml: >> >> >> >> >> >> Financial Records -- General -- Bound Volumes -- >> Financial Reports >> 1905-1908 >> 1 >> 1.0 >> >> >> >> >> >> Financial Records -- General -- Bound Volumes -- >> Financial Reports >> 1909 >> 1 >> 2.0 >> >> >> >> >> >> >> Financial Records -- General -- Bound Volumes -- >> Financial Reports >> 1910-1911 >> 1 >> 3.0 >> >> >> >> (historical background - some of our series restart box numbers at 1, and >> the container ids reflect that, so 89.1 is the 89th box in the collection, >> but 1st in the series. This is not causing the error as far as I can tell, >> since other collections with same numbering style import fine) >> >> >> -- >> Bria L. Parker >> Metadata Librarian >> 2200 McKeldin Library >> University of Maryland >> College Park, MD 20742-7011 >> (301) 405-9067 >> blparker at umd.edu >> > > > > -- > Bria L. Parker > Metadata Librarian > 2200 McKeldin Library > University of Maryland > College Park, MD 20742-7011 > (301) 405-9067 > blparker at umd.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 > > -- Bria L. Parker Metadata Librarian 2200 McKeldin Library University of Maryland College Park, MD 20742-7011 (301) 405-9067 blparker at umd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Wed Jan 25 13:46:18 2017 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Wed, 25 Jan 2017 18:46:18 +0000 Subject: [Archivesspace_Users_Group] Ingesting lcnaf In-Reply-To: References: Message-ID: Dear Kate, This is a plugin but comes with a standard ArchivesSpace installation and is described in the user manual at https://docs.archivesspace.org/Default.htm#AgentsImportLCNAF.htm. It is also described and demonstrated in the Authorities overview video at http://docs.archivesspace.org/screencasts/KLNwebinars/17-AuthoritiesOverview.mp4 (it's discussed at about the 10:45 mark in the video). The ability to import subject headings from LCSH has been added since the instructions were last revised. A few caveats: even though it's distributed with a standard ArchivesSpace, your system administrator has to have enabled use of this plugin for it to be available to you. Also, you have to have advanced data entry privileges or above to access it from the gear menu. You can try it out in the sandbox (http://sandbox.archivesspace.org - use the username admin and the password admin) if you don't have access locally and want to try it out. This plugin is partially proof of concept - a demonstration of what could be done rather than a fully realized mechanism for importing all kinds of authorities. There are many other external databases that could interact with ArchivesSpace this way, and many ways this plugin itself could be improved, and I'd be very interested to hear if others have expanded on this plugin in their local installations. Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) 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, January 25, 2017 11:35 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Ingesting lcnaf Searching list archives and google, I understand someone has written a plugin that ingests LCNAF. Can anyone point me to documentation of what this plugin is meant to do? If you use it, I'd appreciate any documentation you have written or reviews of your experiences with it? Screenshots of agent records post-ingest would be extremely helpful. Thanks! Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu voice: (617) 998-5238 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers -------------- next part -------------- An HTML attachment was scrubbed... URL: From laddmm at miamioh.edu Wed Jan 25 13:57:14 2017 From: laddmm at miamioh.edu (Ladd, Marcus) Date: Wed, 25 Jan 2017 13:57:14 -0500 Subject: [Archivesspace_Users_Group] Can't add new rows in RDE with a template Message-ID: This seems to be a problem that only occurred some time after the last update so I'm not sure what has changed. When a template is active in the Rapid Data Entry view, I am not able to add new rows - either individually or as a batch. Without a template, I can add rows like normal. Has anyone else encountered this? Thanks, Marcus -------- *Marcus Ladd* Special Collections Digital Librarian Miami University, Oxford, OH -------------- next part -------------- An HTML attachment was scrubbed... URL: From pyzynski at fas.harvard.edu Wed Jan 25 17:56:52 2017 From: pyzynski at fas.harvard.edu (Pyzynski, Susan C.) Date: Wed, 25 Jan 2017 22:56:52 +0000 Subject: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person In-Reply-To: References: Message-ID: Hi Noah, I encountered the problem just this week, thanks to you I now know what to do as a work-around. I am having another problem, now that the MARC record is importing properly: the 1XX field, unless it has a $e creator, loads as a subject. I searched JIRA and the listserv, but I don?t see anyone else having this issue. I would have thought the 1XX field would default to creator? Cheers, Susan Susan C. Pyzynski Associate Librarian of Houghton Library for Technical Services Harvard University Cambridge, MA 02138 617-496-6340 (t) pyzynski at fas.harvard.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Wednesday, January 25, 2017 10:44 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person Hi Julie, I ran a test import of a MARC XML record that included the names you provide. I used the MarcXML (Resource) import type. I reproduced error you received. I tried reproducing the error with some of my own records and I think I found the culprit. There seems to be an odd bug in the MarcXML importer where the importer attempts to use the MARC 001 field in the bib record as the authority_id of each agent it creates from that MarcXML record. When there is more than one MARC 700 field in a single MarcXML record it results in duplicate authority_ids, which wrecks the import. When this happens, the import job seems to loop over the same record several times trying to create new agents until it finally throws the error you cited. As a workaround, you can just delete or comment out the MARC001 field in your import file. Here is the line in the importer code that seems to be the culprit: https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_base_map.rb#L292 I?m not sure why the importer is using the control number (Marc 001 field) from the bibliographic record as the authority_id of each agent. The control number identifies the bibliographic record, not the agent. That line should probably be removed from the import code. I?ve submitted a JIRA issue about this bug: https://archivesspace.atlassian.net/browse/AR-1643 I?m wondering if others have encountered this? -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Julie Swierczek Sent: Tuesday, January 24, 2017 12:58 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] interpreting import error messages - problem creating agent person I have a large batch of MARCXML files to import. I keep getting error messages such as "Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction>". Is there some way to figure out which agent is causing the problem? The MARCXML record has thirty-three 700 fields, not to mention other agent fields, so using trial-and-error to find the problem is not a good use of time. I don't see any obvious problems, such as unusual characters in the fields. I have copied the agent fields and the complete error message below. Julie Agent fields: Committee on Militarism in Education (U.S.) Committee on Militarism in Education (U.S.) Archives. Sayre, John Nevin 1884-1977 Thomas, Norman 1884-1968 Wilson, E. Raymond Edward Raymond 1896-1987 Sayre, John Nevin 1884-1977 fast (OCoLC)fst00271556 Thomas, Norman 1884-1968 fast (OCoLC)fst00002998 Wilson, E. Raymond Edward Raymond 1896-1987 fast (OCoLC)fst00018322 Committee on Militarism in Education (U.S.) fast (OCoLC)fst00659515. United States. Army. Reserve Officers' Training Corps. fast (OCoLC)fst00541024. Barnes, Roswell P. Roswell Parkhurst 1901-1949 correspondent Allen, Devere 1891-1955 correspondent Armstrong, Eunice B. correspondent Atkinson, Henry A. correspondent Baldwin, Roger N. Roger Nash 1884-1981 correspondent Boss, Charles F. Charles Frederick 1888- correspondent Brinton, Ellen Starr 1886-1954 correspondent Bromley, Dorothy Dunbar 1896-1986 correspondent Catt, Carrie Chapman 1859-1947 correspondent Coe, George Albert 1862-1951 correspondent Detzer, Dorothy 1893-1981 correspondent Forbes, Rose Dabney 1864-1947 correspondent Johnson, Edwin C. correspondent Kirkpatrick, William 1757-1812 correspondent Lane, Winthrop D. Winthrop David 1887-1962 correspondent Libby, Frederick J. Frederick Joseph 1874-1970 correspondent Moore, Alfred S. correspondent Morgan, Laura Puffer 1874-1962 correspondent Newton, Ray correspondent Olmsted, Mildred Scott 1890-1990 correspondent Page, Kirby 1890-1957 correspondent Pharo, Florence M. correspondent Rankin, Jeannette 1880-1973 correspondent Sayre, John Nevin 1884-1977 correspondent Thomas, Norman 1884-1968 correspondent Tinker, Wellington H. correspondent Van Kirk, Walter W. Walter William 1891-1956 correspondent Villard, Oswald Garrison 1872-1949 correspondent Walser, Kenneth E. correspondent Wilson, E. Raymond Edward Raymond 1896-1987 correspondent Wilson, Theresa L. correspondent Wing, Andrew S. correspondent Wohlforth, Robert correspondent Error message: ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_caf81c0c-b6d7-48e0-8dcd-1811db9b9d5a Created: /subjects/import_71e38336-e415-41ad-9e24-94448bcb0174 Created: /subjects/import_af65aa65-3fb5-4db7-bae8-0d1e45a0a530 Created: /subjects/import_acbed94f-693a-4f58-bd5b-e978665f507a Created: /subjects/import_3b59252c-c5cd-4253-82c6-527ed678b298 Created: /subjects/import_cc64dc68-da3a-4b3d-b5d6-8165a0cea043 Created: /subjects/import_355b896a-57bc-4fec-9f91-860876e5081f Created: /subjects/import_b5e052fc-6e1f-4cc9-94d9-466ca6f850cb Created: /subjects/import_56488c97-6c0d-4440-ae36-0c51adb8308f Created: /subjects/import_14b8289b-4944-4d07-9b50-d49435f96451 Created: /subjects/import_4718b271-bac5-4e9a-b55b-ae1b57a93f1e Created: /subjects/import_307e05a7-6103-4c43-9697-cacb1cbae27e Created: /agents/corporate_entities/import_0c99d3d4-c545-4cf1-bddb-0aae8ebb4a3d Created: /agents/corporate_entities/import_1b627826-6122-4364-932b-e73bf94b5759 Created: /agents/corporate_entities/import_e7d1ae88-4f78-409e-843a-352957943012 Created: /agents/corporate_entities/import_93f40358-0e92-471e-adcc-37b8ee49ea47 Created: /agents/corporate_entities/import_1e514a27-8302-47ce-9e6a-11a8d7bd4caf Created: /agents/people/import_00a266ad-ad5e-40a7-8184-7411fe46c509 Created: /agents/people/import_08e4f942-9799-4aa3-989a-305d5b4ac4b9 Created: /agents/people/import_36ef683d-9478-4d94-a17f-75d6214defa6 Created: /agents/people/import_c1925b29-45e7-410c-9a8e-8333029364be Created: /agents/people/import_cd3f2e14-0e44-4e76-a026-54f16cb41f74 Created: /agents/people/import_6dd6cc26-bd13-4947-a3d4-677fedd2f809 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e5e28e11-92aa-4194-a7ee-f32535b96bf4 Created: /subjects/import_1788a8cc-65bb-4430-b738-5e98bbaf3666 Created: /subjects/import_ea42b8b2-5ebd-4697-b0a5-5690d8af6eee Created: /subjects/import_9e947cc6-07c2-4603-bc92-1293bd3223b6 Created: /subjects/import_b0526537-dfb4-4bdb-961f-2800a53d573b Created: /subjects/import_4b427bfb-a56d-4df0-8327-ffd93c7569d6 Created: /subjects/import_c99df3a7-959e-4b4f-b849-310e09657e10 Created: /subjects/import_8a2d3312-af21-4900-845a-6e510a5f6ee4 Created: /subjects/import_fd620c88-063f-4a89-8709-d0e26530ee1b Created: /subjects/import_52bb7bae-268b-41d5-aca1-d354f452a770 Created: /subjects/import_55a53bae-b69c-4020-a332-2efbc9656ef5 Created: /subjects/import_dc00c75e-ebfb-44a4-8de0-39f9f3b1042d Created: /agents/corporate_entities/import_5245f6ac-a3bf-46a2-aa70-c7baee0f6b02 Created: /agents/corporate_entities/import_25f258ee-7485-4abc-84a3-c4dd381ecf2f Created: /agents/corporate_entities/import_40b66820-036b-45d6-bb0d-1d968e8abb04 Created: /agents/corporate_entities/import_eba62ef9-e127-4882-a6f0-66645d3d4cbb Created: /agents/corporate_entities/import_f68c7e25-c650-458a-82d3-e98045da6026 Created: /agents/people/import_8934b302-68fa-4177-bd72-2ab28ec9798b Created: /agents/people/import_7d8a91df-b816-477b-99a8-348a3d0b288d Created: /agents/people/import_fddf487a-6748-4382-823f-fb9208d91fda Created: /agents/people/import_d25a9742-7008-4933-9f52-c09dd83282bb Created: /agents/people/import_e73f0812-d718-404c-b187-22df456af845 Created: /agents/people/import_4e157d1c-f328-42f9-a544-3653c783642b 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_99a75053-1563-41ec-91d1-16ad98ae117a Created: /subjects/import_b86a5572-4555-45df-8ff8-de96344281df Created: /subjects/import_7f2ce12c-27d5-431a-968b-b89911a1c8b7 Created: /subjects/import_cf05728f-15fe-49e1-9c6f-1638136cff3d Created: /subjects/import_2a06e540-cccf-4c06-adef-7236bf426b44 Created: /subjects/import_76cd94f2-750a-4cf2-a0a1-4b848b282f10 Created: /subjects/import_60c4837b-b94e-4bad-86fd-d4a91c1d0fd4 Created: /subjects/import_32b976f8-b533-407f-92fe-4b5551e7ee86 Created: /subjects/import_2efa9dbd-1181-46c1-b33a-d459d2b35729 Created: /subjects/import_e85bd8e4-6fb3-4259-967c-7fb45297919e Created: /subjects/import_d185ae21-4c29-4939-9158-3c1ffdb941ec Created: /subjects/import_876ca7e2-8c18-43b9-aae6-9d85b398e043 Created: /agents/corporate_entities/import_104cc59e-0d28-46b3-85f5-d83d6a6ac35c Created: /agents/corporate_entities/import_0ac902b8-0e7e-41fe-b0db-72f6e5078958 Created: /agents/corporate_entities/import_5f108b4d-a8cf-4d58-b40f-a0eeed583f4a Created: /agents/corporate_entities/import_e6401bfc-ce36-4990-906e-c0987cb9ec91 Created: /agents/corporate_entities/import_6aa2d667-ff88-455e-af44-d4ddc0786308 Created: /agents/people/import_34c29d35-def9-45ab-a685-d298820b6abd Created: /agents/people/import_1ceee9ff-2d6c-4b73-897f-28a37500339d Created: /agents/people/import_59afa168-0670-421c-9e4b-533d75042027 Created: /agents/people/import_d54d1d25-9686-427a-bd2a-a4273f4cff73 Created: /agents/people/import_47399d5c-cd27-4ff4-b18c-33e169d34356 Created: /agents/people/import_c462238f-66b6-47e6-b421-b470f11a0a01 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c3f64d7b-65a9-43c9-8f1c-954ef922b624 Created: /subjects/import_7c92cc3e-4f13-4423-84ff-6cc307c453f5 Created: /subjects/import_1f89b48c-2eaa-4a21-b084-3d2c61218322 Created: /subjects/import_e4688b9c-12aa-492d-80d4-88a7219a8238 Created: /subjects/import_856f6ba2-94b2-4acc-a5bb-4d487fc1ae6a Created: /subjects/import_ef67b8b5-b7e8-492e-9e9e-452afcf8ee1c Created: /subjects/import_cfbf17d9-a38e-4d30-8767-2fd501af733f Created: /subjects/import_72dc4155-ae9b-4eb2-af20-881af21a7249 Created: /subjects/import_5d6333eb-eac7-4bdd-98e5-842ead80bbd3 Created: /subjects/import_1dc55638-4797-4fb4-8a1d-e319b7d2ec65 Created: /subjects/import_f660f6e3-7561-4618-bf93-b4067637a0b2 Created: /subjects/import_b6160d40-88b2-44f1-882c-ad77600bd28e Created: /agents/corporate_entities/import_2f89c970-7c96-4308-aee9-ffc2e4ab9c89 Created: /agents/corporate_entities/import_9fa8c16e-1e56-43a0-b4d9-d9c29bd4a2b6 Created: /agents/corporate_entities/import_923e4698-4edf-442c-b8fe-58eb7ff3c326 Created: /agents/corporate_entities/import_a9eb9642-429f-40e6-9807-1f96f49c14fc Created: /agents/corporate_entities/import_525e06fb-4d46-4dde-bd27-00c7768429cb Created: /agents/people/import_af36d047-c8d9-484c-95c4-0de126f3a9e0 Created: /agents/people/import_4b43a3d0-b470-4edf-9bde-946e83e050d5 Created: /agents/people/import_46611bfa-59ac-414c-bbcf-924bd18881f7 Created: /agents/people/import_ecee7651-2f31-416c-bd6f-a68fc8d469e0 Created: /agents/people/import_dddc8645-8f26-4810-8138-326ac7e85799 Created: /agents/people/import_1712cee2-e832-4a9a-9bf0-de7469a3fed2 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c6ab2aae-9506-4a4b-b3e4-4dc7507e1fd4 Created: /subjects/import_1ba707a7-5320-415e-97c7-7bd4d9415506 Created: /subjects/import_eb763556-c61c-4c33-a347-15241622a1b2 Created: /subjects/import_5efb51a0-06a5-4768-8146-9547624ac6b3 Created: /subjects/import_73d7047d-8c21-4b79-ad20-53aff2c73ee5 Created: /subjects/import_86897835-e8e7-437b-bf24-9cad9ab2183a Created: /subjects/import_4fcedf51-6210-41ef-b175-7e94ec4941f8 Created: /subjects/import_c7ba965b-b72d-4b07-834f-e174d2718ed8 Created: /subjects/import_15008e65-9733-4735-8027-18a2e5b61edf Created: /subjects/import_31e3a9f2-1eb7-4273-8873-26f0f44303c2 Created: /subjects/import_b1b83b94-4ce8-4ea7-8c23-46e5575a041a Created: /subjects/import_29c0d0ed-efbe-41d7-b041-7d5cdb48a923 Created: /agents/corporate_entities/import_692c63a4-19d0-4946-a199-125d774c2e88 Created: /agents/corporate_entities/import_8236ca94-7cfd-4783-8979-4d3743fb46ba Created: /agents/corporate_entities/import_72516334-0834-43e3-8cf0-704493359de6 Created: /agents/corporate_entities/import_f21d0450-8a1c-4c1c-aaec-53a13c7ea5dd Created: /agents/corporate_entities/import_877420aa-63ef-4f5d-8504-7ac8e27968a6 Created: /agents/people/import_8bd6ff15-be5b-4891-8799-0d436c93a997 Created: /agents/people/import_522b9f78-92ae-4eb6-b8e1-3adeb595eed1 Created: /agents/people/import_280febc2-9095-4a96-b1af-f1ab97a5cd9d Created: /agents/people/import_bbf17ec9-010c-4d27-8651-4949f37fa7bc Created: /agents/people/import_fc0cb8b7-cb88-4384-b3a6-1d9229ca5925 Created: /agents/people/import_a617509c-e27e-4bbf-91c3-30c870999c82 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_e2378314-3b96-467f-b1f0-c0d3e12df517 Created: /subjects/import_42ee60ae-f7fa-4b98-804b-ec8a56c1cb52 Created: /subjects/import_a719691b-1d2f-425d-a70e-a79d83878cd7 Created: /subjects/import_18578880-e8dc-47de-a722-f8687d9d1d2f Created: /subjects/import_6a7377f7-ffdd-4304-8288-ee6927f88d9c Created: /subjects/import_7acb72bf-3abd-4034-8c66-93596950e8e4 Created: /subjects/import_a1477324-3a2f-49e8-a69c-9915d686572b Created: /subjects/import_ffc27919-671f-43a0-953e-f7bb132cf93b Created: /subjects/import_bc16638d-8f55-4a79-bbca-53983365d046 Created: /subjects/import_ff5e71b6-94e0-411d-98b4-300f90536b44 Created: /subjects/import_d283411a-1885-4334-9e90-2b8e9e7a1799 Created: /subjects/import_dbb5a0df-fe9e-40fb-96a4-5c211c259739 Created: /agents/corporate_entities/import_ce5fd920-0de4-4133-a221-02fbbe64fb8d Created: /agents/corporate_entities/import_f8d8c117-9176-4f89-b841-3d6373542ecd Created: /agents/corporate_entities/import_79d839f7-e2d0-402c-94ca-11fcc0b40e4e Created: /agents/corporate_entities/import_245383e2-6e05-463e-9f2d-06881e7eb6bc Created: /agents/corporate_entities/import_8f243882-e530-408b-a8f0-0994e5e799b8 Created: /agents/people/import_a4ee33ab-0d92-4533-b368-d4c231949ea8 Created: /agents/people/import_3ee57000-af58-404b-a2f0-d4f0e3ef99c8 Created: /agents/people/import_9d3b3151-7eac-4e54-960c-3f183084dd85 Created: /agents/people/import_0965bf2a-0f88-42c8-916b-bb9245652b0a Created: /agents/people/import_e828f8e8-acb5-45f3-8b11-35086be50290 Created: /agents/people/import_53291093-e31b-4376-a251-62797b3c3d62 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_c576523f-df9e-4ce5-b254-6935e7c63798 Created: /subjects/import_634080d9-64f8-445f-b1f7-b5b33e3d500f Created: /subjects/import_7fd209ee-a569-46ba-80ec-24107ac5e3cc Created: /subjects/import_9061d8e4-68ec-4e44-b37b-f498d82ef08f Created: /subjects/import_dacb34c3-a51e-40d4-8486-2be7f378dd90 Created: /subjects/import_20151084-6e94-4fae-aa49-00ca2164519f Created: /subjects/import_dd1c8212-26a3-4a74-8f7f-84abbdb74da6 Created: /subjects/import_0c488791-8dff-4b4d-acab-6201615de6fd Created: /subjects/import_85bec3c5-3218-4a41-aeb4-1ba2da8a1397 Created: /subjects/import_24ea01df-4b84-4305-b1e3-5b23c7c64c06 Created: /subjects/import_e561a8e4-ec64-416e-8089-edbb11617339 Created: /subjects/import_a835b0f6-6bb9-47de-9ce2-1fecabd2d39b Created: /agents/corporate_entities/import_522a656d-64f2-471c-969e-fa60c4c0369d Created: /agents/corporate_entities/import_324dfe69-9bd0-4697-98cb-f0b04f37ec28 Created: /agents/corporate_entities/import_24fd8520-1a2a-42f6-a6bb-f1ced4e2046d Created: /agents/corporate_entities/import_ffa3eab4-33bf-42e5-8242-92f14f3917d2 Created: /agents/corporate_entities/import_486e42bf-fc91-44ae-ad1e-666f73499549 Created: /agents/people/import_f1b2b641-43dc-4f0b-b11f-0ed61a57cbac Created: /agents/people/import_3c36e0dc-2fdd-4630-88a6-27d26fbc6374 Created: /agents/people/import_8e5225b2-9eda-45b3-b910-cc873cefc923 Created: /agents/people/import_1a297204-e285-41a1-8f34-722387cd0b99 Created: /agents/people/import_ba187ad3-fbac-43e3-9dd2-283c70b3a93f Created: /agents/people/import_1fb5859c-0131-45fc-b325-7d046ab78266 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_a12fdb96-767b-4d7f-9643-729010d4279a Created: /subjects/import_bdceefa1-d557-41e1-9394-a4fddd8146f1 Created: /subjects/import_1375d63f-31a0-4411-be8b-af4ec1735d7b Created: /subjects/import_9cda693f-d8d5-4b0f-9a9f-07980cd02378 Created: /subjects/import_7d17945c-6ee8-468f-be51-e9c2fcd48951 Created: /subjects/import_c7cc7048-c342-4034-91bb-817033141ed0 Created: /subjects/import_a2955899-3546-419b-8f67-411de3cbce3e Created: /subjects/import_ec37b2ae-72ec-45b7-8381-880672cb4c58 Created: /subjects/import_a69eb008-9cbe-4b24-9a70-cb6e8931b2ca Created: /subjects/import_76d74c50-2e37-4f11-9ee2-5e36643f699d Created: /subjects/import_06fceac1-2c14-4d7c-aad2-6e2cd5ec27fb Created: /subjects/import_b75357fc-94a7-40f3-828b-4ee46ea36e40 Created: /agents/corporate_entities/import_ba44d630-391e-4153-a0ce-543421b7cb50 Created: /agents/corporate_entities/import_7b2c0410-942c-4425-867d-3b4cd8fbeb45 Created: /agents/corporate_entities/import_74751112-da16-41ea-af3b-ca51b2af20a4 Created: /agents/corporate_entities/import_f1a50a2f-4b14-45db-93c8-636da87d1fc4 Created: /agents/corporate_entities/import_fb4693c8-5fd2-444d-9b19-e937538a6164 Created: /agents/people/import_b6b06dd9-a8fc-4d76-a1a6-c94bc423d584 Created: /agents/people/import_3e40eae4-47e0-41c0-9070-b6cf51666ae7 Created: /agents/people/import_a1796499-2819-42a2-96b7-2c8d37a17559 Created: /agents/people/import_f5c5bdc6-19a5-4e56-a996-8fa1171a70bc Created: /agents/people/import_e2390f91-db98-40fc-bad1-aaa59b1dbe2f Created: /agents/people/import_1bac4923-a6ab-4ce0-8262-f8ae3bbd9f9f 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_3419df18-66c1-4b50-84d6-18332ad12c01 Created: /subjects/import_bc25f42e-08f3-425e-990e-49432f1cd69c Created: /subjects/import_cf4a7610-9476-4d6e-a36b-c9d3fadf37d8 Created: /subjects/import_9fe3d9e6-fdd9-4a9b-9098-50c7627f3c48 Created: /subjects/import_59600c70-1d4c-4c0b-b3bb-30ae8df98f26 Created: /subjects/import_06b750e8-8631-471d-b9ba-999e7744626e Created: /subjects/import_1b59deb0-3ee4-4a8a-a131-fc2bd75a2630 Created: /subjects/import_5a5337c2-d8ca-438b-80b1-9dcfe7adbc93 Created: /subjects/import_81cb9d2a-fafc-4377-b748-88f69cd18f59 Created: /subjects/import_e77147c5-2e3b-422e-8fd4-26ea00f4af75 Created: /subjects/import_d7142cdf-1990-4058-b8cd-0370e94c4282 Created: /subjects/import_cf87aa36-2787-4912-b3db-586bb5393618 Created: /agents/corporate_entities/import_f38cd470-a9bf-43a4-87ad-b6f62bc24520 Created: /agents/corporate_entities/import_c76f10bf-5a8d-4166-868e-676547c07629 Created: /agents/corporate_entities/import_0e855bed-57be-48c6-9ee1-440b90f5912d Created: /agents/corporate_entities/import_88ed281b-7a01-4411-8f11-60b6b20085fd Created: /agents/corporate_entities/import_12b7df9f-f3ef-4610-bb65-8df72a1e5ff6 Created: /agents/people/import_641729ce-e12e-48f8-839e-ec1424824db9 Created: /agents/people/import_85a7c0c6-382c-4cfa-9b8f-53a7ad0f956d Created: /agents/people/import_418dd795-4585-43df-855a-0613f9876b35 Created: /agents/people/import_839e43eb-a5aa-4b91-bb5f-abe99e9fedbf Created: /agents/people/import_013a6de7-920b-48fe-906c-30ae132988a2 Created: /agents/people/import_6bf278bb-56ae-4c67-a71d-5048f01d6491 5. STARTED: Cleaning up 5. DONE: Cleaning up ================================================== tester_19046123.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /subjects/import_8b87f313-bcc8-4c31-9695-f4cc363048fc Created: /subjects/import_e2de5496-5b65-44ef-9834-51a094a5a291 Created: /subjects/import_f9bce3bc-eb55-49d6-bd4b-495789585e9a Created: /subjects/import_7d578521-36cc-4077-99ba-878c1be1d875 Created: /subjects/import_b02a1a65-316c-4ae4-b203-a4bb49ab1708 Created: /subjects/import_f450c4c9-3d4c-49c9-9643-49f5e40a0cec Created: /subjects/import_2e304ff5-d29b-4324-9a16-9ef1db9f8ccf Created: /subjects/import_9ac18ff1-081e-45bd-acc0-0c4f45fe02b3 Created: /subjects/import_a93deefd-121a-462a-bea7-62accb216f9e Created: /subjects/import_8ac56763-613f-4e5a-a106-5f8b46ea3e2b Created: /subjects/import_4e124c77-12f4-442c-a9b3-01431e5a573a Created: /subjects/import_154838cb-48b6-4c25-95d2-b5a5a7d9d929 Created: /agents/corporate_entities/import_2f59a661-f724-4a0a-bee5-ecef6e1d31b4 Created: /agents/corporate_entities/import_2f4636b9-f085-4a82-b7bd-ea401c433aa1 Created: /agents/corporate_entities/import_71963e39-5636-4eb0-8414-b224ee386d2a Created: /agents/corporate_entities/import_841224d6-0425-43e1-9b58-53bc86b86ba6 Created: /agents/corporate_entities/import_9a9028e1-36c9-4cec-9c0d-2a863644e5cc Created: /agents/people/import_926d153b-ee74-44d1-881b-0aeab8714bdd Created: /agents/people/import_47d59d8a-e3ad-4e36-a07e-4d55526b3b80 Created: /agents/people/import_b5850cb3-e5c9-4851-bd93-0a9e11e1c34f Created: /agents/people/import_74f33e8a-8608-4997-acec-6878a5a5ba78 Created: /agents/people/import_5a307b09-bd29-4583-8447-9b04a1252724 Created: /agents/people/import_95814b93-ef21-4343-8f63-47ec093dbadb 5. STARTED: Cleaning up 5. DONE: Cleaning up !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORT ERROR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Error: #<RetryTransaction: Problem creating 'agent_person': RetryTransaction> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Heather.Klish at tufts.edu Thu Jan 26 10:47:07 2017 From: Heather.Klish at tufts.edu (Klish, Heather J) Date: Thu, 26 Jan 2017 15:47:07 +0000 Subject: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list In-Reply-To: <12fad1abbb024e9991d3d1e0e457fb4d@ex13-ell-cr-15.home.ku.edu> References: <70BEEB1EDDA0CF458519422A45AEF5D6E9037532@tabvmexdag1mb03.tufts.ad.tufts.edu> <12fad1abbb024e9991d3d1e0e457fb4d@ex13-ell-cr-15.home.ku.edu> Message-ID: <70BEEB1EDDA0CF458519422A45AEF5D6E9038862@tabvmexdag1mb03.tufts.ad.tufts.edu> Thanks Miloche. We are logging in with system admin privs - that's why it's strange that we can't see all the repositories. Heather . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heather Klish | Systems Librarian TTS : Library Technology Services Tufts University heather.klish at tufts.edu | 617.627.5853 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kottman, Miloche Sent: Wednesday, January 25, 2017 12:53 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list I would double-check the access/permissions. If you are logged in as a system administrator then you should be able to see all the repositories. Anyone else would need to have their permissions set up for each repository by having a system administrator open the "missing" repository and adding individual users to appropriate groups via the Manage Groups function. --Miloche Miloche Kottman Head of Cataloging and Archival Processing University of Kansas Libraries Lawrence, KS 66045 mkottman at ku.edu 785-864-3916 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Klish, Heather J Sent: Wednesday, January 25, 2017 10:38 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Can't see all repositories in manage repositories list Hi everyone, We have two repositories on our production server - our original repository that we've been using for a while and one that we've just created. When we click on the 'Manage Repositories' link, we only see the new repository in the list. We've replicated the new repository on a test server and on that server, we can see both repositories in the list. Can anyone help with why we can't see both repositories on our production server? Thanks! Heather . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heather Klish | Systems Librarian TTS : Library Technology Services Tufts University heather.klish at tufts.edu | 617.627.5853 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jteitelbaum at pabmc.net Mon Jan 30 09:45:18 2017 From: jteitelbaum at pabmc.net (Teitelbaum, Jesse) Date: Mon, 30 Jan 2017 09:45:18 -0500 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> References: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: Chris, Before I try to find a plug-in for this, do you know if this would have been addressed in the 1.5.2? Jesse From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Tuesday, January 24, 2017 4:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"?can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the ?sort title.? For example, in ARCHON, the ?Papers of John Doe? are listed under D for DOE, but when brought over to AS, all the collections beginning with ?Papers of?? are listed under ?P.? Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From christine.dibella at lyrasis.org Mon Jan 30 10:25:53 2017 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Mon, 30 Jan 2017 15:25:53 +0000 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: References: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: Dear Jesse, The Archon migration tool was refactored in November 2015. Aside from a small change made in September 2016 to fix a bug with parsing certain kinds of digital objects, further changes have not been made since then. There is a field called ?Finding Aid Filing Title? in ArchivesSpace which provides the capability of differentiating between how the resource is represented in its title field and formal finding aid title field and how it appears in browse and search lists. If there?s a value in Finding Aid Filing Title, this is what appears in browse and search lists in the staff interface. From a functional standpoint, that would be the place to enter your Sort Titles from Archon. Have others migrating from Archon had the same experience? How have you addressed it with your migrated data? Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Teitelbaum, Jesse Sent: Monday, January 30, 2017 9:45 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Chris, Before I try to find a plug-in for this, do you know if this would have been addressed in the 1.5.2? Jesse From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Tuesday, January 24, 2017 4:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"?can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the ?sort title.? For example, in ARCHON, the ?Papers of John Doe? are listed under D for DOE, but when brought over to AS, all the collections beginning with ?Papers of?? are listed under ?P.? Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From jazairi at bc.edu Mon Jan 30 10:41:03 2017 From: jazairi at bc.edu (Adam Jazairi) Date: Mon, 30 Jan 2017 10:41:03 -0500 Subject: [Archivesspace_Users_Group] Cataloged note field In-Reply-To: References: Message-ID: You were spot on, Noah -- migrating to an earlier version fixed it. Thanks for sharing your experience. For anyone else facing this problem, try migrating from Archivists' Toolkit to ArchivesSpace v1.2.0, then upgrading to v1.5.2. The cataloged notes should map first to collection management in v1.2.0, then to outcome notes in v1.5.2. In our case, the field didn't migrate directly to versions 1.3.x or higher. Adam -- Adam Jazairi Digital Library Applications Developer Boston College Libraries (617) 552-1404 jazairi at bc.edu On Tue, Jan 24, 2017 at 3:57 PM, Noah Huffman wrote: > Strange. My cataloged_note content from AT mapped to the Outcome Note > field of the event record (see screenshot). But, I migrated from AT to an > early version of ASpace (1.3?). I wonder if the mappings have changed > since. Let me know what you discover. > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Adam > Jazairi > *Sent:* Tuesday, January 24, 2017 3:24 PM > *To:* Archivesspace Users Group lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Cataloged note field > > > > Hi Noah, > > > > Thanks for getting back to me. I should've clarified that though we're > currently running 1.5.2, we used the plugin to migrate to 1.4.2 first. > Sorry for any confusion. > > > > Our ArchivesSpace instance maps cataloged notes to events, but only > partially. The events include the date accessioned and the linked record, > but not the note itself. I wonder if this is an issue with the Archivists' > Toolkit migration plugin. I'll have a look at the source code and see if > anything looks awry. > > > > Adam > > > -- > > Adam Jazairi > > Digital Library Applications Developer > > Boston College Libraries > > (617) 552-1404 > > jazairi at bc.edu > > > > On Tue, Jan 24, 2017 at 2:47 PM, Noah Huffman > wrote: > > Hi Adam, > > > > It?s recommended that you run the AT migration plugin to ArchivesSpace > v.1.4.2 and then upgrade to ArchivesSpace to 1.5.2. > > > > Even so, I?m not clear on where the cataloged_note field maps. According > to the AT migration mapping documentation > , > it should map to a collection management record, but I?m not seeing that > field in collection management. As part of the 1.4.2 to 1.5.X upgrade, > some collection management fields were converted to event records. You > might check to see if any of your cataloged_note fields from AT now exist > as event records in ArchivesSpace. I?m seeing some in my database, so I > suspect that is what happened. > > > > -Noah > > > > ================ > > Noah Huffman > > Archivist for Metadata, Systems, and Digital Records > > David M. Rubenstein Rare Book & Manuscript Library > > Duke University | 919-660-5982 <(919)%20660-5982> > > http://library.duke.edu/rubenstein/ > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Adam > Jazairi > *Sent:* Tuesday, January 24, 2017 10:13 AM > *To:* Archivesspace Users Group lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Cataloged note field > > > > Hello all, > > > > My institution is in the process of migrating from Archivists' Toolkit to > ArchivesSpace, and we've noticed that the cataloged note field doesn't seem > to map. This seems to be intentional, based on the discussion in the > following ticket: https://archivesspace.atlassian.net/browse/AR-827 > > > > > This is problematic for us because some of our records have important data > in this field that we don't want to lose. Has anyone else encountered this > issue? If so, I'd appreciate any advice on how to resolve it. > > > > For reference, we're running ArchivesSpace 1.5.2 and used the AT > migration plugin > > to migrate our database. > > > > Thanks, > > > > Adam > > > -- > > Adam Jazairi > > Digital Library Applications Developer > > Boston College Libraries > > (617) 552-1404 > > jazairi at bc.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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 22339 bytes Desc: not available URL: From lhocking at litchfieldhistoricalsociety.org Mon Jan 30 10:57:18 2017 From: lhocking at litchfieldhistoricalsociety.org (Linda Hocking) Date: Mon, 30 Jan 2017 15:57:18 +0000 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: References: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: We had the same issue. Also, the ?finding aid title? under ?Finding Aid Data? shows up like this- ?Archon Finding Aid Title? We are fixing it manually. If there?s a better way that doesn?t require a migration do-over, please share. And out of curiosity, is there a reason for a different Finding Aid Title in Finding Aid Data? Would that ever be different from the ?Title? field under basic information? Thanks! Linda Linda M. Hocking, CA Curator of Library & Archives Litchfield Historical Society P.O. Box 385 Litchfield, CT 06759 860-567-4501 http://www.litchfieldhistoricalsociety.org archivist at litchfieldhistoricalsociety.org eboardman.tumblr.com From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Monday, January 30, 2017 10:26 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Dear Jesse, The Archon migration tool was refactored in November 2015. Aside from a small change made in September 2016 to fix a bug with parsing certain kinds of digital objects, further changes have not been made since then. There is a field called ?Finding Aid Filing Title? in ArchivesSpace which provides the capability of differentiating between how the resource is represented in its title field and formal finding aid title field and how it appears in browse and search lists. If there?s a value in Finding Aid Filing Title, this is what appears in browse and search lists in the staff interface. From a functional standpoint, that would be the place to enter your Sort Titles from Archon. Have others migrating from Archon had the same experience? How have you addressed it with your migrated data? Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Teitelbaum, Jesse Sent: Monday, January 30, 2017 9:45 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Chris, Before I try to find a plug-in for this, do you know if this would have been addressed in the 1.5.2? Jesse From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Tuesday, January 24, 2017 4:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"?can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the ?sort title.? For example, in ARCHON, the ?Papers of John Doe? are listed under D for DOE, but when brought over to AS, all the collections beginning with ?Papers of?? are listed under ?P.? Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From jteitelbaum at pabmc.net Mon Jan 30 11:18:02 2017 From: jteitelbaum at pabmc.net (Teitelbaum, Jesse) Date: Mon, 30 Jan 2017 11:18:02 -0500 Subject: [Archivesspace_Users_Group] ARCHON sort titles not migrating In-Reply-To: References: <551D255B-C5A2-40ED-9428-9713442445F6@illinois.edu> Message-ID: Thanks Christine. I did find the fields you mentioned and I was able to manually edit them. Jesse Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Monday, January 30, 2017 10:26 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Dear Jesse, The Archon migration tool was refactored in November 2015. Aside from a small change made in September 2016 to fix a bug with parsing certain kinds of digital objects, further changes have not been made since then. There is a field called ?Finding Aid Filing Title? in ArchivesSpace which provides the capability of differentiating between how the resource is represented in its title field and formal finding aid title field and how it appears in browse and search lists. If there?s a value in Finding Aid Filing Title, this is what appears in browse and search lists in the staff interface. From a functional standpoint, that would be the place to enter your Sort Titles from Archon. Have others migrating from Archon had the same experience? How have you addressed it with your migrated data? Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Teitelbaum, Jesse Sent: Monday, January 30, 2017 9:45 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Chris, Before I try to find a plug-in for this, do you know if this would have been addressed in the 1.5.2? Jesse From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Tuesday, January 24, 2017 4:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] ARCHON sort titles not migrating Hi, According the the specs, this should be migrating into a user defined field with value "Sort Title"?can you check to see if it ended up there, Jesse? I don't think, however, that ASpace would sort on that field w/out a plugin. Thanks, Chris Prom Univeristy of Illinois On Jan 24, 2017, at 2:48 PM, Teitelbaum, Jesse > wrote: We are migrating ARCHON records to AS 1.4.2 and the collection titles are coming over alphabetically by title and not the ?sort title.? For example, in ARCHON, the ?Papers of John Doe? are listed under D for DOE, but when brought over to AS, all the collections beginning with ?Papers of?? are listed under ?P.? Does 1.5.2 fix this? Or is a plug-in required? Thanks. Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net www.house.state.pa.us/BMC/archives _______________________________________________ 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: From laney.mcglohon at lyrasis.org Mon Jan 30 11:22:30 2017 From: laney.mcglohon at lyrasis.org (Laney McGlohon) Date: Mon, 30 Jan 2017 16:22:30 +0000 Subject: [Archivesspace_Users_Group] Laney McGlohon Introduction Message-ID: I would like to introduce myself to the ArchivesSpace community. I?m Laney McGlohon, the ArchivesSpace Technical Lead. I started on Monday, January 23, 2017, and will be based in Atlanta, Georgia. I?m an information scientist, software developer, librarian, and data wrangler. I have been writing software for over 30 years and have worked in many different kinds of libraries - public, newspaper, academic, and cultural heritage institutions. My experience with special collections and archives spans more than seven years during which time I worked full-time at the Getty Research Institute (GRI) in Los Angeles and as a consultant and volunteer at the Museum of Ventura County California. I was responsible for managing the Archivists' Toolkit (AT) installations and the import of finding aids in many different digital formats and the export of EADs into the institutional discovery systems and the Online Archive of California. Before I left the GRI in 2014, I had several opportunities to work with the early migration tool from AT to ArchivesSpace and, upon my arrival at Stanford University Libraries, I assisted the University Archivist in the AT migration to the local ArchivesSpace installation. I?m very excited to have this opportunity to work with archivists and other special collections-oriented colleagues again. I look forward to working with all of you on improving the ArchivesSpace application and enhancing the deployment and usability of the software. Expect to hear more about the engagement of a broader set of developers in future development of the application. I will be attending Code4Lib 2017 anticipating opportunities to connect with like-minded people there. You?ll be hearing more from Christine and me in the weeks to come about future plans, but in the meantime, feel free to get in touch at any point. I can be reached at laney.mcglohon at lyrasis.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: