Just wanted to record a problem with ASpace and see if anyone has a solution. When I try to add a sibling to a folder list it adds the sibling to the bottom of the list - not where I want it to go. I then have to drag the newly created folder up to where I wanted to put it. Anyone else have this problem / know a solution? When I do this I have the folder before the one I want to create highlighted, thinking that the added sibling would fall in after the highlighted one but that doesn't happen.
Thanks for any help! I'll search this list history for answers too. -Greta Greta Kuriger Suiter Collections Archivist | Institute Archives & Special Collections MIT Libraries, Bldg. 14N-118 | 77 Massachusetts Ave., Cambridge, MA 02139-4307 [email protected] My pronouns: she, her, hers -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, November 16, 2016 9:40 AM To: [email protected] Subject: Archivesspace_Users_Group Digest, Vol 40, Issue 2 Send Archivesspace_Users_Group mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Archivesspace_Users_Group digest..." Today's Topics: 1. Re: LibraryHost (Tummino, Annie) 2. Re: LibraryHost (Tummino, Annie) 3. Check out the test site of the new ArchivesSpace PUI (Custer, Mark) 4. Re: Check out the test site of the new ArchivesSpace PUI (Custer, Mark) 5. new technical support option for ArchivesSpace members (Christine Di Bella) 6. Job Posting: Digital Initiatives Librarian @ Brandeis University (Hong Jing) 7. Job posting for Vanderbilt University (ArchivesSpaceHome) 8. DACS 7.1.6 equivalent in ArchivesSpace (Cheri Crist) 9. Problems working with archival object with large number of direct children (Sally Vermaaten) 10. Re: [archivesspace] Problems working with archival object with large number of direct children (Runyon, Carolyn) 11. Re: Problems working with archival object with large number of direct children (Ryan Edwards) 12. Re: Problems working with archival object with large number of direct children (Jason Loeffler) 13. Re: Problems working with archival object with large number of direct children (Jason Loeffler) 14. Re: Problems working with archival object with large number of direct children (Joshua D. Shaw) 15. Re: Problems working with archival object with large number of direct children (James Bullen) 16. Re: Problems working with archival object with large number of direct children (Jason Loeffler) 17. Re: Problems working with archival object with large number of direct children (James Bullen) 18. A user who is set as manager of a collection can not create containers... (Gadsby, Eric T.) 19. Re: Problems working with archival object with large number of direct children (Jason Loeffler) 20. Re: Problems working with archival object with large number of direct children (James Bullen) 21. Re: A user who is set as manager of a collection can not create containers... (Payten Giles) 22. Re: A user who is set as manager of a collection can not create containers... (Payten Giles) 23. Re: A user who is set as manager of a collection can not create containers... (Gadsby, Eric T.) 24. Re: Problems working with archival object with large number of direct children (Joshua D. Shaw) 25. Re: A user who is set as manager of a collection can not create containers... (Yvonne Kester) ---------------------------------------------------------------------- Message: 1 Date: Thu, 10 Nov 2016 22:06:49 +0000 From: "Tummino, Annie" <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] LibraryHost Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" P.S. I should add that this is really for creating resources (finding aids) and assumes you have already set up a repository and created an accession. From: [email protected] [mailto:[email protected]] On Behalf Of Clifford Allen Sent: Thursday, October 27, 2016 3:57 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LibraryHost Thanks Annie -- we're in the same boat. Good to know that the training is on hold; maybe that'll give us a little time to get more of our stuff together. I would be interested in seeing that user guide if it is not too much trouble. This is virgin territory for us though I have worked in porting out EAD to DAMs before... it's a little different. Cheers, Clifford On Thu, Oct 27, 2016 at 3:21 PM, Tummino, Annie <[email protected]<mailto:[email protected]>> wrote: Hi Allen, We just started using LibraryHost a couple of months ago and it is working out great so far. I sent this same query to the SAA Lone Arrangers list and only got positive feedback about LibraryHost, which made me confident about moving forward. They also offer a free trial which is nice. Because we have no EAD files to begin with, we are starting with a relatively clean slate, so we didn?t need assistance with migration. Generally speaking, I am sure starting from scratch is a lot easier than what large institutions are confronting. I?ll note that the LibraryHost expert on ASpace is currently on maternity leave, so they are not able to do a training until she returns, but we are moving forward with branding in her absence. I have found that for our needs, I?ve been getting along just fine using the ASpace help center documentation, and it?s not really been a problem that we had to put off the training. We are creating a user guide which I?d be happy to share with you. Hope this helps, Annie From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Clifford Allen Sent: Thursday, October 27, 2016 11:27 AM To: [email protected]<mailto:[email protected]> Subject: [Archivesspace_Users_Group] LibraryHost Hi All, Forgive me if this has been brought up before and is a dead-horse topic, but as someone who is just beginning to implement ArchivesSpace, what are the advantages/disadvantages of LibraryHost as compared to Atlas and LYRASIS? As we are a small institution their lower price points are attractive, but I'm wondering if that is because certain necessary services/aspects aren't being offered. Thanks so much in advance for weighing in. Sincerely, -- Clifford Allen Archivist | The Watermill Center | Robert Wilson 115 W 29th St., 10th Fl., New York, NY 10001 main: +1 212 253 7484 x 113<tel:%2B1%20212%20253%207484%20x%20113> [email protected]<mailto:[email protected]> | www.watermillcenter.org<http://www.watermillcenter.org> JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup> The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York. _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Clifford Allen Archivist | The Watermill Center | Robert Wilson 115 W 29th St., 10th Fl., New York, NY 10001 main: +1 212 253 7484 x 113 [email protected]<mailto:[email protected]> | www.watermillcenter.org<http://www.watermillcenter.org> JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup> The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161110/2b464b8f/attachment-0001.html> ------------------------------ Message: 2 Date: Thu, 10 Nov 2016 22:08:25 +0000 From: "Tummino, Annie" <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] LibraryHost Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Sorry folks! I was trying to send this to Clifford and mistakenly sent to the whole list. Well, if anyone else wants to see our Guide, there you have it. That?s what happens when you try to do things at the end of the day when you are about to leave. Best, Annie From: [email protected] [mailto:[email protected]] On Behalf Of Tummino, Annie Sent: Thursday, November 10, 2016 5:07 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LibraryHost P.S. I should add that this is really for creating resources (finding aids) and assumes you have already set up a repository and created an accession. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Clifford Allen Sent: Thursday, October 27, 2016 3:57 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LibraryHost Thanks Annie -- we're in the same boat. Good to know that the training is on hold; maybe that'll give us a little time to get more of our stuff together. I would be interested in seeing that user guide if it is not too much trouble. This is virgin territory for us though I have worked in porting out EAD to DAMs before... it's a little different. Cheers, Clifford On Thu, Oct 27, 2016 at 3:21 PM, Tummino, Annie <[email protected]<mailto:[email protected]>> wrote: Hi Allen, We just started using LibraryHost a couple of months ago and it is working out great so far. I sent this same query to the SAA Lone Arrangers list and only got positive feedback about LibraryHost, which made me confident about moving forward. They also offer a free trial which is nice. Because we have no EAD files to begin with, we are starting with a relatively clean slate, so we didn?t need assistance with migration. Generally speaking, I am sure starting from scratch is a lot easier than what large institutions are confronting. I?ll note that the LibraryHost expert on ASpace is currently on maternity leave, so they are not able to do a training until she returns, but we are moving forward with branding in her absence. I have found that for our needs, I?ve been getting along just fine using the ASpace help center documentation, and it?s not really been a problem that we had to put off the training. We are creating a user guide which I?d be happy to share with you. Hope this helps, Annie From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Clifford Allen Sent: Thursday, October 27, 2016 11:27 AM To: [email protected]<mailto:[email protected]> Subject: [Archivesspace_Users_Group] LibraryHost Hi All, Forgive me if this has been brought up before and is a dead-horse topic, but as someone who is just beginning to implement ArchivesSpace, what are the advantages/disadvantages of LibraryHost as compared to Atlas and LYRASIS? As we are a small institution their lower price points are attractive, but I'm wondering if that is because certain necessary services/aspects aren't being offered. Thanks so much in advance for weighing in. Sincerely, -- Clifford Allen Archivist | The Watermill Center | Robert Wilson 115 W 29th St., 10th Fl., New York, NY 10001 main: +1 212 253 7484 x 113<tel:%2B1%20212%20253%207484%20x%20113> [email protected]<mailto:[email protected]> | www.watermillcenter.org<http://www.watermillcenter.org> JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup> The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York. _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Clifford Allen Archivist | The Watermill Center | Robert Wilson 115 W 29th St., 10th Fl., New York, NY 10001 main: +1 212 253 7484 x 113 [email protected]<mailto:[email protected]> | www.watermillcenter.org<http://www.watermillcenter.org> JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup> The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161110/9fa832cd/attachment-0001.html> ------------------------------ Message: 3 Date: Fri, 11 Nov 2016 14:47:59 +0000 From: "Custer, Mark" <[email protected]> To: "Archivesspace Users Group ([email protected])" <[email protected]> Subject: [Archivesspace_Users_Group] Check out the test site of the new ArchivesSpace PUI Message-ID: <bn3pr08mb131830f17aa189bfae17674e8c...@bn3pr08mb1318.namprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Dear ArchivesSpace colleagues: I am writing to provide an update about the development of the new ArchivesSpace Public Interface. As a reminder, here is the release timeline that we drafted and shared earlier in the year: * candidate release, 12/16/2016 * official testing period, 12/19/2016 - 2/28/2017 * official release, 3/31/2017 We're still on track to have everything done in time for an official release in March, but it's likely that we will push that candidate release date back a few weeks. Since we haven't changed the date yet I don't have a new date to share at this time, but if we do push the date back it will probably be postponed to January. In the meantime, I also wanted to share a link with everyone to a working version of the new public interface so that you could see things in action before everything is finished. You can access that website here: http://pui.hudmol.com/ (and thanks to Hudson Molonglo for hosting this site for us during the development process!!!) Please note that this site is still a work in progress. You might stumble across bugs, and it's possible that some features could stop working from one day to the next. Also, not all features have been added (e.g. "Record Group" / Classification pages) or fully implemented yet (e.g. the "Collection organization" navigation sidebar). In any event, this site will provide a more interactive way to explore the development process before the design has been finished. In the coming weeks, we will also create a few introductory videos for the new PUI that will focus on and explain a few of the new, exciting features. You can also follow along with the development process at the ArchivesSpace PUI wiki: https://archivesspace.atlassian.net/wiki/display/ADC/Public+Interface+Enhancement+Project<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_ADC_Public-26-2343-3BInterface-26-2343-3BEnhancement-26-2343-3BProject&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=EVhE7hGgEiFUwEqMCd6wOUjBAjB-m9qD3KnMCwCnzGk&s=9J-sJPfocPm1WF4QSm9MvnLFX4jAWKWwRSNMGBqB5jc&e=> More news soon, Mark Custer On behalf of the ArchivesSpace Public Interface development group. * James Bullen, Hudson Molonglo * Mark Cooper, LYRASIS * Mark Custer, Yale University * Bobbi Fox, Harvard University * Payten Giles, Hudson Molonglo * Brian Hoffman, Consultant * Susan Pyzynski, Harvard University * Mark Triggs, Hudson Molonglo * Brad Westbrook, ArchivesSpace * Melissa Wisner, Yale University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161111/b1ef5532/attachment-0001.html> ------------------------------ Message: 4 Date: Fri, 11 Nov 2016 15:18:52 +0000 From: "Custer, Mark" <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] Check out the test site of the new ArchivesSpace PUI Message-ID: <bn3pr08mb1318741ec76bd5401a2dbc918c...@bn3pr08mb1318.namprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" All, I regret that I didn't include at least one search example with the previous announcement. Since today's the first day of the 2016 World Chess Championship, here's a timely one: http://pui.hudmol.com/search?utf8=%E2%9C%93&q=chess I'll also come back to this example later on in one of the introductory videos, since I think it might be a good case to explain how the new archival inheritance feature will work once it's implemented (see https://archivesspace.atlassian.net/browse/AR-1300). All my best, Mark From: [email protected] [mailto:[email protected]] On Behalf Of Custer, Mark Sent: Friday, 11 November, 2016 9:48 AM To: Archivesspace Users Group ([email protected]) Subject: [Archivesspace_Users_Group] Check out the test site of the new ArchivesSpace PUI Dear ArchivesSpace colleagues: I am writing to provide an update about the development of the new ArchivesSpace Public Interface. As a reminder, here is the release timeline that we drafted and shared earlier in the year: * candidate release, 12/16/2016 * official testing period, 12/19/2016 - 2/28/2017 * official release, 3/31/2017 We're still on track to have everything done in time for an official release in March, but it's likely that we will push that candidate release date back a few weeks. Since we haven't changed the date yet I don't have a new date to share at this time, but if we do push the date back it will probably be postponed to January. In the meantime, I also wanted to share a link with everyone to a working version of the new public interface so that you could see things in action before everything is finished. You can access that website here: http://pui.hudmol.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__pui.hudmol.com_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=mHKsaKwdKo1giNBjiurqEHO18veSK4gHeKMYhEh3Y_s&s=cT2ROAsYvRYwVtJMlVbfF0Uij0OilGhnxk88YuxsoKM&e=> (and thanks to Hudson Molonglo for hosting this site for us during the development process!!!) Please note that this site is still a work in progress. You might stumble across bugs, and it's possible that some features could stop working from one day to the next. Also, not all features have been added (e.g. "Record Group" / Classification pages) or fully implemented yet (e.g. the "Collection organization" navigation sidebar). In any event, this site will provide a more interactive way to explore the development process before the design has been finished. In the coming weeks, we will also create a few introductory videos for the new PUI that will focus on and explain a few of the new, exciting features. You can also follow along with the development process at the ArchivesSpace PUI wiki: https://archivesspace.atlassian.net/wiki/display/ADC/Public+Interface+Enhancement+Project<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_ADC_Public-26-2343-3BInterface-26-2343-3BEnhancement-26-2343-3BProject&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=EVhE7hGgEiFUwEqMCd6wOUjBAjB-m9qD3KnMCwCnzGk&s=9J-sJPfocPm1WF4QSm9MvnLFX4jAWKWwRSNMGBqB5jc&e=> More news soon, Mark Custer On behalf of the ArchivesSpace Public Interface development group. * James Bullen, Hudson Molonglo * Mark Cooper, LYRASIS * Mark Custer, Yale University * Bobbi Fox, Harvard University * Payten Giles, Hudson Molonglo * Brian Hoffman, Consultant * Susan Pyzynski, Harvard University * Mark Triggs, Hudson Molonglo * Brad Westbrook, ArchivesSpace * Melissa Wisner, Yale University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161111/5b70d59c/attachment-0001.html> ------------------------------ Message: 5 Date: Mon, 14 Nov 2016 14:19:02 +0000 From: Christine Di Bella <[email protected]> To: Archivesspace Users Group <[email protected]>, Archivesspace Member Reps <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [Archivesspace_Users_Group] new technical support option for ArchivesSpace members Message-ID: <dm2pr0801mb08486fead74e619903115941f1...@dm2pr0801mb0848.namprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Dear ArchivesSpace members, ArchivesSpace is happy to announce an additional way for ArchivesSpace members to receive technical support. Courtesy of resources approved by the ArchivesSpace Governance Board, staff from LYRASIS Technology Services will be taking an added role in providing help to individual ArchivesSpace members and contributing to the technical documentation for the application. As befits a Community-Supported Software application, when you need help, we encourage you to look to the community first by posting to the Users Group listserv. Given the breadth of knowledge and experience on the listserv, and the sheer number of people participating (currently over 850 subscribers), many issues will be resolved quickly this way and everyone will benefit from the discussion of the issue and its solution. If you are unable to resolve the issue using the listserv, or if you think you need more individualized assistance from the start, please email [email protected]<mailto:[email protected]> with your issue. If it requires technical assistance beyond the program staff's expertise, a program staff member will create a ticket and LYRASIS Technology Services staff will follow up with you. When applicable, once the issue has been resolved, LYRASIS Technology Services staff will also update related technical documentation on GitHub to make the issue easier to resolve for other users. Please note that while there is no limit on the number of requests a member organization may make for assistance, support provided through membership is geared toward helping people learn how to help themselves and there are limits to the complexity of issues that can be addressed. For example, membership does not include hosting, customization, data migration, or intensive data repair. We can provide you with strong guidance in these areas, but we can't undertake the solutions themselves for you. If your issue requires assistance beyond what is possible through membership, we will alert you to this and suggest alternatives. Please continue to file bug reports and feature requests via JIRA at http://support.archivesspace.org. More information is available at https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Report+a+Bug and https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Request+a+New+Feature. Program staff can assist you with filing these if you need help, or if a bug report or feature request comes out of your support request. We hope that you will find the availability of this additional level of technical assistance helpful. If you have any questions, or if you need assistance, please email the program team at [email protected]<mailto:[email protected]>. Christine Christine Di Bella Community Outreach Manager [email protected]<mailto:[email protected]> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:[email protected]] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/ffeb11b2/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7645 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/ffeb11b2/attachment-0001.png> ------------------------------ Message: 6 Date: Mon, 14 Nov 2016 09:52:00 -0500 From: Hong Jing <[email protected]> To: [email protected] Subject: [Archivesspace_Users_Group] Job Posting: Digital Initiatives Librarian @ Brandeis University Message-ID: <CAMFN=hy+8kkyfw9yenkkmbvadktfbwhszrgxv8598edswmb...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" *Please excuse for cross-posting* *Job Posting: Digital Initiatives Librarian (Job ID: 525688)* Brandeis University seeks to hire a Digital Initiatives Librarian to be responsible for administration and configuration of institutional repository and related systems and applications. *Examples of Key Responsibilities:* - Responsible for administration and configuration of institutional repository and related systems and applications, including but not limited to creation of new IR communities and collections. Outreach to communities, for planning and performing batch loads of new collections, implementation of workflow, technical processes and methodology, and administering authorizations and roles within the institutional repository and related applications. - Works in conjunction with library systems staff, vendor support staff and open source communities, and Scholarly Communications to troubleshoot, resolve and escalate problems; works in conjunction with library systems staff to coordinate and perform application and system upgrades. Creates specifications and scripting for metadata transformation and crosswalks. - Performs technical support for faculty and staff in the use of the institutional repository and related applications, and assists with process and workflow development. Works as a member of the library team to plan and implement changes to delivered public interfaces; works as a member of the library team to integrate digital collections with other campus-wide applications. - Assists with creation of short and long-term plans for digitization of selected materials, working with content specialists and faculty members to determine priorities for digitization. Works as a member of Library & Technology Service (LTS) teams to assist faculty and staff in decision making for new collections. Receives requests for assistance with digital materials, and evaluates the appropriateness of those materials for inclusion in current or future digital asset systems. - Performs execution and support of LTS institutional repository policies and procedures, and assists in the development of policies as needed. Serves as resident authority for metadata and digitization standards. Helps guide and ensure adherence to capture standards, metadata standards, preservation standards, technical workflow and quality control. - Back-up core function of systems in the library and be available for on-call *Qualifications:* MLS or MSI degree from an ALA-accredited institution of higher education; 3-5 years experience with library digital repositories Experience developing and managing digital software (DSpace, ArchivesSpace); knowledge and experience working in Unix or Linux systems at the CLI Proven engagement in the broader library systems community with a focus on administering and supporting digital initiatives applications and services; familiarity with metadata standards such as EAD, MARC, Dublic Core Strong organizational, communication, customer service and interpersonal skills; ability to work well with faculty, staff, and students. *Preferred skills:* Familiarity with digitization projects and standards for various materials, e.g. electronic theses and dissertations, manuscripts, photographs and audio and video recordings Experience with scripting languages and using APIs; experience with CSS, XML, XSL, XSLT and harvesting standards; experience in a research library or academic library *How to Apply:* Submit cover letter and resume as a single document at http://www.brandeis.edu/humanresources/jobs/external.html. Elect option for "External Applicant". Sort the job listing by clicking the *Job ID* column heading. Locate the desired job listing by Job ID. Click the job title and then Apply Now. *Closing Statement:* Brandeis University is an affirmative action/equal opportunity employer and encourages minorities, women, disabled individuals, and eligible veterans to apply. It is the policy of the University not to discriminate against any applicant or employee on the basis of race, ancestry, color, religion, sex, sexual orientation, age, genetic information, national origin, disability, veteran status, or on the basis of any other legally protected category. -- Jenny Jing Manager, Library Systems Library & Technology Services, Brandeis University Library 781-736-4698 [email protected] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/9596dc4d/attachment-0001.html> ------------------------------ Message: 7 Date: Tue, 15 Nov 2016 13:56:15 +0000 From: ArchivesSpaceHome <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: [Archivesspace_Users_Group] Job posting for Vanderbilt University Message-ID: <dm2pr0801mb0848d4e2205ef8d204522ef6f1...@dm2pr0801mb0848.namprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Posted on behalf of Valerie Hotchkiss. From: Hotchkiss, Valerie [mailto:[email protected]] Sent: Monday, November 14, 2016 2:53 PM To: ArchivesSpaceHome <[email protected]> Subject: Job posting Dear Archives Space colleagues, Since this job description specifically entails introducing ArchivesSpace at Vanderbilt, I wonder if you can help us spread the word about it? https://vanderuniv.taleo.net/careersection/.vu_cs/jobdetail.ftl?job=1605657 Many thanks, v Valerie Hotchkiss University Librarian The Jean and Alexander Heard Library<http://www.library.vanderbilt.edu/> Vanderbilt University (615) 322-4782 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/5444b374/attachment-0001.html> ------------------------------ Message: 8 Date: Tue, 15 Nov 2016 12:34:55 -0500 From: Cheri Crist <[email protected]> To: [email protected] Subject: [Archivesspace_Users_Group] DACS 7.1.6 equivalent in ArchivesSpace Message-ID: <CAGmhTeNHR5u_t2H8hB3Eg6ynv28Lta=aqfvxemfhf031mf3...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi list, I'm finding that somewhere in the annals of time, individual pieces of ephemera were given museum object numbers in TMS, and these numbers are written on the items. I'm wondering if anyone out there has a best practice for recording these numbers in AS. I thought recording the TMS number in the Component Unique Identifier field at item level would work, but it doesn't show up in the pdf. (It does show in the public interface, however.) What have other people done? Thanks, Cheri Cheri Crist Project Archivist Richard and Ronay Menschel Library George Eastman Museum 900 East Ave. Rochester, NY 14607 [email protected] (585)271-3361 ext. 280 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/7ae31a86/attachment-0001.html> ------------------------------ Message: 9 Date: Tue, 15 Nov 2016 14:37:56 -0500 From: Sally Vermaaten <[email protected]> To: [email protected], Archivesspace Users Group <[email protected]> Subject: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <calt9ybsgyktab7esllcxz6qck64txr3yszzqdipxn0womxz...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi everyone, We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: - it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy - it takes a couple of minutes to open any archival object in the series in edit mode and - it takes a couple of minutes to save changes to any archival object within the series Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records? The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem. We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style? Thanks, Weatherly and Sally -- Sally Vermaaten Project Manager, Archival Systems New York University Libraries 1-212-992-6259 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/f4355ae5/attachment-0001.html> ------------------------------ Message: 10 Date: Tue, 15 Nov 2016 19:46:25 +0000 From: "Runyon, Carolyn" <[email protected]> To: "[email protected]" <[email protected]>, Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] [archivesspace] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" We have noticed this as well. In fact, one of our resource records is large enough that it won?t open on the staff interface at all. Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 [email protected]<mailto:[email protected]>, (423) 425-4503 Dept. 6456, LIB 439D On Nov 15, 2016, at 2:37 PM, Sally Vermaaten <[email protected]<mailto:[email protected]>> wrote: Hi everyone, We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: * it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy * it takes a couple of minutes to open any archival object in the series in edit mode and * it takes a couple of minutes to save changes to any archival object within the series Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records? The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem. We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style? Thanks, Weatherly and Sally -- Sally Vermaaten Project Manager, Archival Systems New York University Libraries 1-212-992-6259 -- You received this message because you are subscribed to the Google Groups "ArchivesSpace" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/987641d9/attachment-0001.html> ------------------------------ Message: 11 Date: Tue, 15 Nov 2016 19:49:02 +0000 From: Ryan Edwards <[email protected]> To: Archivesspace Users Group <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <dm5pr05mb3244d4492ccbd4de4817c07cbe...@dm5pr05mb3244.namprd05.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hello Sally, We?ve also noticed that it can take a while (2-3 minutes) to load one of our largest resources, even after we increased the physical RAM on our server. -Ryan Ryan Edwards Digital Access and Systems Librarian Getty Research Institute From: [email protected] [mailto:[email protected]] On Behalf Of Sally Vermaaten Sent: Tuesday, November 15, 2016 11:38 AM To: [email protected]; Archivesspace Users Group <[email protected]> Subject: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Hi everyone, We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy ? it takes a couple of minutes to open any archival object in the series in edit mode and ? it takes a couple of minutes to save changes to any archival object within the series Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records? The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem. We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style? Thanks, Weatherly and Sally -- Sally Vermaaten Project Manager, Archival Systems New York University Libraries 1-212-992-6259 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/255cb23a/attachment-0001.html> ------------------------------ Message: 12 Date: Tue, 15 Nov 2016 15:25:20 -0500 From: Jason Loeffler <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <cap4gjsw_9wbo6zvzxajq1cfap-ck47hwnow8aebfa_p5ffj...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Sally, Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree <http://jstree.com/> and/or loading* all JSON objects* associated with a resource into the browser. Maybe an ASpace dev can weigh in. >From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report. At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements. JL On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected]> wrote: > Hi everyone, > > We're running into an issue with a large resource record in ArchivesSpace > and wonder if anyone has experienced a similar issue. In one resource > record, we have a series/archival object with around 19,000 direct > children/archival objects. We've found that: > > - it takes several minutes to open the series in the 'tree' navigation > view and then, once opened scrolling through series is very slow / laggy > - it takes a couple of minutes to open any archival object in the > series in edit mode and > - it takes a couple of minutes to save changes to any archival object > within the series > > Does anyone else have a similarly large archival object in a resource > record? If so, have you observed the same long load/save time when editing > the component records? > > The slow load time does not seem to be affected by memory allocation; > we've tried increasing the speed / size of the server and it seemed to have > no effect. We'd definitely appreciate any other suggestions for how we > might fix or work around the problem. > > We also wonder if this performance issue is essentially caused by the > queries being run to generate the UI view - i.e. perhaps in generating the > resource 'tree' view, all data for the whole series (all 19k archival > objects) is being retrieved and stored in memory? If so, we wondered if it > would be possible and would make sense to change the queries running during > tree generation, etc. to only retrieve some batches at a time, lazy loading > style? > > Thanks, > Weatherly and Sally > > -- > Sally Vermaaten > Project Manager, Archival Systems > New York University Libraries > 1-212-992-6259 > > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/41bbc85b/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: report.pdf Type: application/pdf Size: 81907 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/41bbc85b/attachment-0001.pdf> ------------------------------ Message: 13 Date: Tue, 15 Nov 2016 15:35:06 -0500 From: Jason Loeffler <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <cap4gjsx8himvyapcha-psfrhro44ermm9tv-8awo-dqrhf3...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I should add that application performance was a hot topic in August last year. Some of the issues described have been mitigated and/or implemented; others not so much. http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002285.html http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002319.html http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002346.html On Tue, Nov 15, 2016 at 3:25 PM, Jason Loeffler <[email protected]> wrote: > Hi Sally, > > Definitely, yes. We have many resources with 5,000 or more archival object > records. We've deployed on some pretty decent Amazon EC2 boxes (16GB > memory, burstable CPU, etc.) with negligible improvement. I have a feeling > that this is not a resource allocation issue. Looking at the web inspector, > most of the time is spent negotiating jstree <http://jstree.com/> and/or > loading* all JSON objects* associated with a resource into the browser. > Maybe an ASpace dev can weigh in. > > From the sysadmin side, Maureen Callahan at Yale commissioned Percona to > evaluate ArchivesSpace and MySQL performance. I've attached the report. Let > me know if you need any help interpreting the report. > > At some point, and quite apart from this thread, I hope we can > collectively revisit the staff interface architecture and recommend > improvements. > > JL > > On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected]> > wrote: > >> Hi everyone, >> >> We're running into an issue with a large resource record in ArchivesSpace >> and wonder if anyone has experienced a similar issue. In one resource >> record, we have a series/archival object with around 19,000 direct >> children/archival objects. We've found that: >> >> - it takes several minutes to open the series in the 'tree' >> navigation view and then, once opened scrolling through series is very >> slow >> / laggy >> - it takes a couple of minutes to open any archival object in the >> series in edit mode and >> - it takes a couple of minutes to save changes to any archival object >> within the series >> >> Does anyone else have a similarly large archival object in a resource >> record? If so, have you observed the same long load/save time when editing >> the component records? >> >> The slow load time does not seem to be affected by memory allocation; >> we've tried increasing the speed / size of the server and it seemed to have >> no effect. We'd definitely appreciate any other suggestions for how we >> might fix or work around the problem. >> >> We also wonder if this performance issue is essentially caused by the >> queries being run to generate the UI view - i.e. perhaps in generating the >> resource 'tree' view, all data for the whole series (all 19k archival >> objects) is being retrieved and stored in memory? If so, we wondered if it >> would be possible and would make sense to change the queries running during >> tree generation, etc. to only retrieve some batches at a time, lazy loading >> style? >> >> Thanks, >> Weatherly and Sally >> >> -- >> Sally Vermaaten >> Project Manager, Archival Systems >> New York University Libraries >> 1-212-992-6259 >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> [email protected] >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/e441cee3/attachment-0001.html> ------------------------------ Message: 14 Date: Tue, 15 Nov 2016 20:46:44 +0000 From: "Joshua D. Shaw" <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Hi all ? We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type. If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache. I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet. One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out. Best, Joshua From: <[email protected]> on behalf of Jason Loeffler <[email protected]> Reply-To: Archivesspace Users Group <[email protected]> Date: Tuesday, November 15, 2016 at 3:25 PM To: Archivesspace Users Group <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Hi Sally, Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree<http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in. >From the sysadmin side, Maureen Callahan at Yale commissioned Percona to >evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me >know if you need any help interpreting the report. At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements. JL On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected]<mailto:[email protected]>> wrote: Hi everyone, We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy ? it takes a couple of minutes to open any archival object in the series in edit mode and ? it takes a couple of minutes to save changes to any archival object within the series Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records? The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem. We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style? Thanks, Weatherly and Sally -- Sally Vermaaten Project Manager, Archival Systems New York University Libraries 1-212-992-6259<tel:1-212-992-6259> _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/f1ff16f0/attachment-0001.html> ------------------------------ Message: 15 Date: Wed, 16 Nov 2016 10:17:37 +1100 From: James Bullen <[email protected]> To: Archivesspace Users Group <[email protected]>, [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Hi all, As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority. It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able. Cheers, James ? James Bullen Hudson Molonglo > On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected]> > wrote: > > Hi all ? > > We at Dartmouth have experienced similar issues. We have some large resources > as well (one has 60K+ objects in the tree) and anything that involves a save > or rearrangement (moving a file around, etc) can take a *lot* of time (many > minutes) and may cause an error ? typically of the ?another user is modifying > this record? type. > > If we have to do any modifications to a resource of that size, we a) budget a > lot of time and b) do things in small increments ? ie don?t move more than a > couple of files around at a time. It?s not a great solution, but it does > minimize some of the headache. > > I *think* (but haven?t had the time to really dig into this) that one reason > the error comes about is because the indexer steps on/collides with the > process that the save/arrangement kicked off. We are still running 1.3 and > hope that some of our issues will be mitigated when we move to 1.5.1, though > we know that not all of them have been resolved yet. > > One other data point is that we?ve got a plugin that runs as a background job > doing a bunch of importing. This background job touches some of the larger > resources, but does *not* cause the errors and long save times, which leads > me to believe that a lot of the problem is in the frontend ? perhaps with the > way the tree is populated - as Jason pointed out. > > Best, > Joshua > > From: <[email protected] > <mailto:[email protected]>> on behalf > of Jason Loeffler <[email protected] <mailto:[email protected]>> > Reply-To: Archivesspace Users Group > <[email protected] > <mailto:[email protected]>> > Date: Tuesday, November 15, 2016 at 3:25 PM > To: Archivesspace Users Group > <[email protected] > <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Subject: Re: [Archivesspace_Users_Group] Problems working with archival > object with large number of direct children > > Hi Sally, > > Definitely, yes. We have many resources with 5,000 or more archival object > records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, > burstable CPU, etc.) with negligible improvement. I have a feeling that this > is not a resource allocation issue. Looking at the web inspector, most of the > time is spent negotiating jstree <http://jstree.com/> and/or loading all JSON > objects associated with a resource into the browser. Maybe an ASpace dev can > weigh in. > > > From the sysadmin side, Maureen Callahan at Yale commissioned Percona to > evaluate ArchivesSpace and MySQL performance. I've attached the report. Let > me know if you need any help interpreting the report. > > At some point, and quite apart from this thread, I hope we can collectively > revisit the staff interface architecture and recommend improvements. > > JL > > On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected] > <mailto:[email protected]>> wrote: >> Hi everyone, >> >> We're running into an issue with a large resource record in ArchivesSpace >> and wonder if anyone has experienced a similar issue. In one resource >> record, we have a series/archival object with around 19,000 direct >> children/archival objects. We've found that: >> ? it takes several minutes to open the series in the 'tree' >> navigation view and then, once opened scrolling through series is very slow >> / laggy >> ? it takes a couple of minutes to open any archival object in the >> series in edit mode and >> ? it takes a couple of minutes to save changes to any archival >> object within the series >> Does anyone else have a similarly large archival object in a resource >> record? If so, have you observed the same long load/save time when editing >> the component records? >> >> The slow load time does not seem to be affected by memory allocation; we've >> tried increasing the speed / size of the server and it seemed to have no >> effect. We'd definitely appreciate any other suggestions for how we might >> fix or work around the problem. >> >> We also wonder if this performance issue is essentially caused by the >> queries being run to generate the UI view - i.e. perhaps in generating the >> resource 'tree' view, all data for the whole series (all 19k archival >> objects) is being retrieved and stored in memory? If so, we wondered if it >> would be possible and would make sense to change the queries running during >> tree generation, etc. to only retrieve some batches at a time, lazy loading >> style? >> >> Thanks, >> Weatherly and Sally >> >> -- >> Sally Vermaaten >> Project Manager, Archival Systems >> New York University Libraries >> 1-212-992-6259 <tel:1-212-992-6259> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> [email protected] >> <mailto:[email protected]> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> > > !DSPAM:582b7444314351074817778! > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > <mailto:[email protected]> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> > > > !DSPAM:582b7444314351074817778! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/4054a705/attachment-0001.html> ------------------------------ Message: 16 Date: Tue, 15 Nov 2016 18:28:44 -0500 From: Jason Loeffler <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <cap4gjsvcnku_79parxd4j-s88z7-6g8hdywdrhrzwvwwm_r...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Thanks so much, James. Can you tell me if there's a script available for generating an arbitrary number of test records? Something similar to Drupal's devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x> hooks? Jason Loeffler Technology Consultant | The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York [email protected] (347) 405-0826 minorscience (Skype) On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <[email protected]> wrote: > > Hi all, > > As part of our new role as ArchivesSpace development partner, we will be > addressing issues like this as a priority. > > It is still early days and we?re working with the folks at the > ArchivesSpace program on a release schedule, so we can?t make any > definitive statements yet, but please know that we are aware of this issue > and will address it as soon as we are able. > > > Cheers, > James > > > ? > James Bullen > Hudson Molonglo > > > > On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected]> > wrote: > > Hi all ? > > We at Dartmouth have experienced similar issues. We have some large > resources as well (one has 60K+ objects in the tree) and anything that > involves a save or rearrangement (moving a file around, etc) can take a * > *lot** of time (many minutes) and may cause an error ? typically of the > ?another user is modifying this record? type. > > If we have to do any modifications to a resource of that size, we a) > budget a lot of time and b) do things in small increments ? ie don?t move > more than a couple of files around at a time. It?s not a great solution, > but it does minimize some of the headache. > > I **think** (but haven?t had the time to really dig into this) that one > reason the error comes about is because the indexer steps on/collides with > the process that the save/arrangement kicked off. We are still running 1.3 > and hope that some of our issues will be mitigated when we move to 1.5.1, > though we know that not all of them have been resolved yet. > > One other data point is that we?ve got a plugin that runs as a background > job doing a bunch of importing. This background job touches some of the > larger resources, but does **not** cause the errors and long save times, > which leads me to believe that a lot of the problem is in the frontend ? > perhaps with the way the tree is populated - as Jason pointed out. > > Best, > Joshua > > *From: *<[email protected]> on > behalf of Jason Loeffler <[email protected]> > *Reply-To: *Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Date: *Tuesday, November 15, 2016 at 3:25 PM > *To: *Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Cc: *"[email protected]" <[email protected]> > *Subject: *Re: [Archivesspace_Users_Group] Problems working with archival > object with large number of direct children > > Hi Sally, > > Definitely, yes. We have many resources with 5,000 or more archival object > records. We've deployed on some pretty decent Amazon EC2 boxes (16GB > memory, burstable CPU, etc.) with negligible improvement. I have a feeling > that this is not a resource allocation issue. Looking at the web inspector, > most of the time is spent negotiating jstree <http://jstree.com/> and/or > loading* all JSON objects* associated with a resource into the browser. > Maybe an ASpace dev can weigh in. > > > From the sysadmin side, Maureen Callahan at Yale commissioned Percona to > evaluate ArchivesSpace and MySQL performance. I've attached the report. Let > me know if you need any help interpreting the report. > > At some point, and quite apart from this thread, I hope we can > collectively revisit the staff interface architecture and recommend > improvements. > > JL > > On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected]> > wrote: > > Hi everyone, > > We're running into an issue with a large resource record in ArchivesSpace > and wonder if anyone has experienced a similar issue. In one resource > record, we have a series/archival object with around 19,000 direct > children/archival objects. We've found that: > ? it takes several minutes to open the series in the 'tree' > navigation view and then, once opened scrolling through series is very slow > / laggy > ? it takes a couple of minutes to open any archival object in the > series in edit mode and > ? it takes a couple of minutes to save changes to any archival > object within the series > Does anyone else have a similarly large archival object in a resource > record? If so, have you observed the same long load/save time when editing > the component records? > > The slow load time does not seem to be affected by memory allocation; > we've tried increasing the speed / size of the server and it seemed to have > no effect. We'd definitely appreciate any other suggestions for how we > might fix or work around the problem. > > We also wonder if this performance issue is essentially caused by the > queries being run to generate the UI view - i.e. perhaps in generating the > resource 'tree' view, all data for the whole series (all 19k archival > objects) is being retrieved and stored in memory? If so, we wondered if it > would be possible and would make sense to change the queries running during > tree generation, etc. to only retrieve some batches at a time, lazy loading > style? > > Thanks, > Weatherly and Sally > > -- > Sally Vermaaten > Project Manager, Archival Systems > New York University Libraries > 1-212-992-6259 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:582b7444314351074817778! ___________________________________ > ____________ > Archivesspace_Users_Group mailing list > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:582b7444314351074817778! > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/129b5b6e/attachment-0001.html> ------------------------------ Message: 17 Date: Wed, 16 Nov 2016 10:56:38 +1100 From: James Bullen <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Hi Jason - I?m not aware of a script like this. Cheers ? James > On Nov 16, 2016, at 10:28 AM, Jason Loeffler <[email protected]> wrote: > > Thanks so much, James. Can you tell me if there's a script available for > generating an arbitrary number of test records? Something similar to Drupal's > devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x> hooks? > > Jason Loeffler > Technology Consultant | The American Academy in Rome > Minor Science | Application Development & Metadata Strategy > Brooklyn, New York > [email protected] <mailto:[email protected]> > (347) 405-0826 > minorscience (Skype) > > > > On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > As part of our new role as ArchivesSpace development partner, we will be > addressing issues like this as a priority. > > It is still early days and we?re working with the folks at the ArchivesSpace > program on a release schedule, so we can?t make any definitive statements > yet, but please know that we are aware of this issue and will address it as > soon as we are able. > > > Cheers, > James > > > ? > James Bullen > Hudson Molonglo > > > >> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi all ? >> >> We at Dartmouth have experienced similar issues. We have some large >> resources as well (one has 60K+ objects in the tree) and anything that >> involves a save or rearrangement (moving a file around, etc) can take a >> *lot* of time (many minutes) and may cause an error ? typically of the >> ?another user is modifying this record? type. >> >> If we have to do any modifications to a resource of that size, we a) budget >> a lot of time and b) do things in small increments ? ie don?t move more than >> a couple of files around at a time. It?s not a great solution, but it does >> minimize some of the headache. >> >> I *think* (but haven?t had the time to really dig into this) that one reason >> the error comes about is because the indexer steps on/collides with the >> process that the save/arrangement kicked off. We are still running 1.3 and >> hope that some of our issues will be mitigated when we move to 1.5.1, though >> we know that not all of them have been resolved yet. >> >> One other data point is that we?ve got a plugin that runs as a background >> job doing a bunch of importing. This background job touches some of the >> larger resources, but does *not* cause the errors and long save times, which >> leads me to believe that a lot of the problem is in the frontend ? perhaps >> with the way the tree is populated - as Jason pointed out. >> >> Best, >> Joshua >> >> From: <[email protected] >> <mailto:[email protected]>> on behalf >> of Jason Loeffler <[email protected] <mailto:[email protected]>> >> Reply-To: Archivesspace Users Group >> <[email protected] >> <mailto:[email protected]>> >> Date: Tuesday, November 15, 2016 at 3:25 PM >> To: Archivesspace Users Group >> <[email protected] >> <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> Subject: Re: [Archivesspace_Users_Group] Problems working with archival >> object with large number of direct children >> >> Hi Sally, >> >> Definitely, yes. We have many resources with 5,000 or more archival object >> records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, >> burstable CPU, etc.) with negligible improvement. I have a feeling that this >> is not a resource allocation issue. Looking at the web inspector, most of >> the time is spent negotiating jstree <http://jstree.com/> and/or loading all >> JSON objects associated with a resource into the browser. Maybe an ASpace >> dev can weigh in. >> >> >> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to >> evaluate ArchivesSpace and MySQL performance. I've attached the report. Let >> me know if you need any help interpreting the report. >> >> At some point, and quite apart from this thread, I hope we can collectively >> revisit the staff interface architecture and recommend improvements. >> >> JL >> >> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi everyone, >>> >>> We're running into an issue with a large resource record in ArchivesSpace >>> and wonder if anyone has experienced a similar issue. In one resource >>> record, we have a series/archival object with around 19,000 direct >>> children/archival objects. We've found that: >>> ? it takes several minutes to open the series in the 'tree' >>> navigation view and then, once opened scrolling through series is very slow >>> / laggy >>> ? it takes a couple of minutes to open any archival object in the >>> series in edit mode and >>> ? it takes a couple of minutes to save changes to any archival >>> object within the series >>> Does anyone else have a similarly large archival object in a resource >>> record? If so, have you observed the same long load/save time when editing >>> the component records? >>> >>> The slow load time does not seem to be affected by memory allocation; we've >>> tried increasing the speed / size of the server and it seemed to have no >>> effect. We'd definitely appreciate any other suggestions for how we might >>> fix or work around the problem. >>> >>> We also wonder if this performance issue is essentially caused by the >>> queries being run to generate the UI view - i.e. perhaps in generating the >>> resource 'tree' view, all data for the whole series (all 19k archival >>> objects) is being retrieved and stored in memory? If so, we wondered if it >>> would be possible and would make sense to change the queries running during >>> tree generation, etc. to only retrieve some batches at a time, lazy loading >>> style? >>> >>> Thanks, >>> Weatherly and Sally >>> >>> -- >>> Sally Vermaaten >>> Project Manager, Archival Systems >>> New York University Libraries >>> 1-212-992-6259 <tel:1-212-992-6259> >>> >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> [email protected] >>> <mailto:[email protected]> >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >> >> wbr>582b7444314351074817778! _______________________________________________ >> Archivesspace_Users_Group mailing list >> [email protected] >> <mailto:[email protected]> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >> >> >> !DSPAM:582b7444314351074817778! > > > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > <mailto:[email protected]> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> > > > !DSPAM:582b9a4b138833087816299! > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > <mailto:[email protected]> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> > > > !DSPAM:582b9a4b138833087816299! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/7b414b69/attachment-0001.html> ------------------------------ Message: 18 Date: Wed, 16 Nov 2016 00:47:14 +0000 From: "Gadsby, Eric T." <[email protected]> To: "[email protected]" <[email protected]> Subject: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report: ?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.? Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks! Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected]<mailto:[email protected]> 410-704-3340 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/2170c700/attachment-0001.html> ------------------------------ Message: 19 Date: Wed, 16 Nov 2016 02:10:52 +0000 (UTC) From: Jason Loeffler <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <e0903b9c708fd3bf.5eee58aa-f43d-496f-aa20-9f8755c27...@mail.outlook.com> Content-Type: text/plain; charset="utf-8" Thanks, James. Just wondering if there's a load test battery for a large dataset. I can generate a large dataset if you think it is useful for your work.? On Tue, Nov 15, 2016 at 6:56 PM -0500, "James Bullen" <[email protected]> wrote: Hi Jason - I?m not aware of a script like this. ?Cheers ? James On Nov 16, 2016, at 10:28 AM, Jason Loeffler <[email protected]> wrote: Thanks so much, James. Can you tell me if there's a script available for generating an arbitrary number of test records? Something similar to Drupal's devel?generate?hooks? Jason LoefflerTechnology Consultant |?The American Academy in RomeMinor Science | Application Development & Metadata StrategyBrooklyn, New [email protected](347) 405-0826minorscience (Skype) On Tue, Nov 15, 2016 at 6:17 PM, James Bullen?<[email protected]>?wrote: Hi all, As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority. It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able. Cheers,James ?James BullenHudson Molonglo On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected]> wrote: Hi all ??We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.?If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.?I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.?One other data point is that we?ve got ! a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.?Best,Joshua?From:?<[email protected]> on behalf of Jason Loeffler <[email protected]> Reply-To:?Archivesspace Users Group <[email protected]> Date:?Tuesday, November 15, 2016 at 3:25 PM To:?Archivesspace Users Group <[email protected]> Cc:?"[email protected]" <[email protected]> Subject:?Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children?Hi Sally,?Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating?jstree?and/or loading?all JSON objects?associated with a resource into the browser. Maybe an ASpace dev can weigh in. >From the sysadmin side, Maureen Callahan at Yale commissioned Percona to >evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me >know if you need any help interpreting the report.?At some point, and quite >apart from this thread, I hope we can collectively revisit the staff interface >architecture and recommend improvements.??JL?On Tue, Nov 15, 2016 at 2:37 PM, >Sally Vermaaten <[email protected]> wrote:Hi everyone,?We're running >into an issue with a large resource record in ArchivesSpace and wonder if >anyone has experienced a similar issue.?In one resource record, we have a >series/archival object with around 19,000 direct children/archival objects. >We've found that: ???????????it takes several minutes to open the series in >the 'tree' navigation view and then, once opened scrolling through series is >very slow / laggy??????????it takes a couple of minutes to open any archival >object in the series in edit mode and???????????it takes a couple of minut! es to sav e changes to any archival object within the seriesDoes anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records???The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.?We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style???Thanks,Weatherly?and Sally?--?Sally Vermaaten Project Manager, Archival Systems New York University Libraries1-212-992-6259 _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group?wbr>582b7444314351074817778!?_______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:582b7444314351074817778! _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:582b9a4b138833087816299! _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:582b9a4b138833087816299! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/272967ce/attachment-0001.html> ------------------------------ Message: 20 Date: Wed, 16 Nov 2016 13:34:17 +1100 From: James Bullen <[email protected]> To: Archivesspace Users Group <[email protected]> Cc: [email protected] Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" That could be useful thanks Jason. Cheers ? James > On Nov 16, 2016, at 1:10 PM, Jason Loeffler <[email protected]> wrote: > > > Thanks, James. Just wondering if there's a load test battery for a large > dataset. I can generate a large dataset if you think it is useful for your > work. > > > > > On Tue, Nov 15, 2016 at 6:56 PM -0500, "James Bullen" <[email protected] > <mailto:[email protected]>> wrote: > > > Hi Jason - I?m not aware of a script like this. Cheers ? James > > >> On Nov 16, 2016, at 10:28 AM, Jason Loeffler <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks so much, James. Can you tell me if there's a script available for >> generating an arbitrary number of test records? Something similar to >> Drupal's devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x> >> hooks? >> >> Jason Loeffler >> Technology Consultant | The American Academy in Rome >> Minor Science | Application Development & Metadata Strategy >> Brooklyn, New York >> [email protected] <mailto:[email protected]> >> (347) 405-0826 >> minorscience (Skype) >> >> >> >> On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi all, >> >> As part of our new role as ArchivesSpace development partner, we will be >> addressing issues like this as a priority. >> >> It is still early days and we?re working with the folks at the ArchivesSpace >> program on a release schedule, so we can?t make any definitive statements >> yet, but please know that we are aware of this issue and will address it as >> soon as we are able. >> >> >> Cheers, >> James >> >> >> ? >> James Bullen >> Hudson Molonglo >> >> >> >>> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi all ? >>> >>> We at Dartmouth have experienced similar issues. We have some large >>> resources as well (one has 60K+ objects in the tree) and anything that >>> involves a save or rearrangement (moving a file around, etc) can take a >>> *lot* of time (many minutes) and may cause an error ? typically of the >>> ?another user is modifying this record? type. >>> >>> If we have to do any modifications to a resource of that size, we a) budget >>> a lot of time and b) do things in small increments ? ie don?t move more >>> than a couple of files around at a time. It?s not a great solution, but it >>> does minimize some of the headache. >>> >>> I *think* (but haven?t had the time to really dig into this) that one >>> reason the error comes about is because the indexer steps on/collides with >>> the process that the save/arrangement kicked off. We are still running 1.3 >>> and hope that some of our issues will be mitigated when we move to 1.5.1, >>> though we know that not all of them have been resolved yet. >>> >>> One other data point is that we?ve got a plugin that runs as a background >>> job doing a bunch of importing. This background job touches some of the >>> larger resources, but does *not* cause the errors and long save times, >>> which leads me to believe that a lot of the problem is in the frontend ? >>> perhaps with the way the tree is populated - as Jason pointed out. >>> >>> Best, >>> Joshua >>> >>> From: <[email protected] >>> <mailto:[email protected]>> on behalf >>> of Jason Loeffler <[email protected] <mailto:[email protected]>> >>> Reply-To: Archivesspace Users Group >>> <[email protected] >>> <mailto:[email protected]>> >>> Date: Tuesday, November 15, 2016 at 3:25 PM >>> To: Archivesspace Users Group >>> <[email protected] >>> <mailto:[email protected]>> >>> Cc: "[email protected] >>> <mailto:[email protected]>" <[email protected] >>> <mailto:[email protected]>> >>> Subject: Re: [Archivesspace_Users_Group] Problems working with archival >>> object with large number of direct children >>> >>> Hi Sally, >>> >>> Definitely, yes. We have many resources with 5,000 or more archival object >>> records. We've deployed on some pretty decent Amazon EC2 boxes (16GB >>> memory, burstable CPU, etc.) with negligible improvement. I have a feeling >>> that this is not a resource allocation issue. Looking at the web inspector, >>> most of the time is spent negotiating jstree <http://jstree.com/> and/or >>> loading all JSON objects associated with a resource into the browser. Maybe >>> an ASpace dev can weigh in. >>> >>> >>> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to >>> evaluate ArchivesSpace and MySQL performance. I've attached the report. Let >>> me know if you need any help interpreting the report. >>> >>> At some point, and quite apart from this thread, I hope we can collectively >>> revisit the staff interface architecture and recommend improvements. >>> >>> JL >>> >>> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Hi everyone, >>>> >>>> We're running into an issue with a large resource record in ArchivesSpace >>>> and wonder if anyone has experienced a similar issue. In one resource >>>> record, we have a series/archival object with around 19,000 direct >>>> children/archival objects. We've found that: >>>> ? it takes several minutes to open the series in the 'tree' >>>> navigation view and then, once opened scrolling through series is very >>>> slow / laggy >>>> ? it takes a couple of minutes to open any archival object in the >>>> series in edit mode and >>>> ? it takes a couple of minutes to save changes to any archival >>>> object within the series >>>> Does anyone else have a similarly large archival object in a resource >>>> record? If so, have you observed the same long load/save time when editing >>>> the component records? >>>> >>>> The slow load time does not seem to be affected by memory allocation; >>>> we've tried increasing the speed / size of the server and it seemed to >>>> have no effect. We'd definitely appreciate any other suggestions for how >>>> we might fix or work around the problem. >>>> >>>> We also wonder if this performance issue is essentially caused by the >>>> queries being run to generate the UI view - i.e. perhaps in generating the >>>> resource 'tree' view, all data for the whole series (all 19k archival >>>> objects) is being retrieved and stored in memory? If so, we wondered if it >>>> would be possible and would make sense to change the queries running >>>> during tree generation, etc. to only retrieve some batches at a time, lazy >>>> loading style? >>>> >>>> Thanks, >>>> Weatherly and Sally >>>> >>>> -- >>>> Sally Vermaaten >>>> Project Manager, Archival Systems >>>> New York University Libraries >>>> 1-212-992-6259 <tel:1-212-992-6259> >>>> >>>> _______________________________________________ >>>> Archivesspace_Users_Group mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>>> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >>> >>> wbr>582b7444314351074817778! _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> [email protected] >>> <mailto:[email protected]> >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >>> >>> >>> wbr class="">582b7444314351074817778! >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> [email protected] >> <mailto:[email protected]> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >> >> >> !DSPAM:582b9a4b138833087816299! >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> [email protected] >> <mailto:[email protected]> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >> >> >> !DSPAM:582b9a4b138833087816299! > > !DSPAM:582bc03b277649809715286! > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > !DSPAM:582bc03b277649809715286! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/da104852/attachment-0001.html> ------------------------------ Message: 21 Date: Wed, 16 Nov 2016 18:20:26 +1100 From: Payten Giles <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Hi there Eric, Access to the ?Create? for containers is provided by the?update_container_record role. ?It looks like this isn?t granted to managers (repository-managers) by default. ?This has a bug vibe and I?ll ensure a JIRA issue is recorded. In the meantime, you can expand the roles available to your repository managers by following these steps: 1. Login as an administrator 2. Ensure the repository you?d like to update is selected 3. Under the ?cog? icon next to the repository name, select "Manage Groups? 4. Select ?Edit? next to the?repository-managers group 5. Under ?Members can?, ensure the checkbox for "create/update top container records? is selected 6. Save Group Hopefully the ?Create? action will now be available! Thanks, Payten On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. ([email protected]) wrote: I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report:? ?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.?? Our server has only been in production for a few weeks and is set-up per the?http://www.archivesspace.org?recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks!? Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected] 410-704-3340 _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/21a11577/attachment-0001.html> ------------------------------ Message: 22 Date: Wed, 16 Nov 2016 04:05:24 -0300 From: Payten Giles <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... Message-ID: <CAFwQ+jR8UXQ=pjX=itikO8uLe3Nb8NjXwuT=n_p4m5ib8q7...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi there Eric, Access to the ?Create? for containers is provided by the update_container_record role. It looks like this isn?t granted to managers (repository-managers) by default. This has a bug vibe and I?ll ensure a JIRA issue is recorded. In the meantime, you can expand the roles available to your repository managers by following these steps: 1. Login as an administrator 2. Ensure the repository you?d like to update is selected 3. Under the ?cog? icon next to the repository name, select "Manage Groups? 4. Select ?Edit? next to the repository-managers group 5. Under ?Members can?, ensure the checkbox for "create/update top container records? is selected 6. Save Group Hopefully the ?Create? action will now be available! Thanks, Payten On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. ([email protected]) wrote: I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report: ?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.? Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks! Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected] 410-704-3340 _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/f0e12ee0/attachment-0001.html> ------------------------------ Message: 23 Date: Wed, 16 Nov 2016 12:32:22 +0000 From: "Gadsby, Eric T." <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Payten, Thanks I will have the users try that and report back. Thanks for your help! Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected]<mailto:[email protected]> 410-704-3340 On Nov 16, 2016, at 2:20 AM, Payten Giles <[email protected]<mailto:[email protected]>> wrote: Hi there Eric, Access to the ?Create? for containers is provided by the update_container_record role. It looks like this isn?t granted to managers (repository-managers) by default. This has a bug vibe and I?ll ensure a JIRA issue is recorded. In the meantime, you can expand the roles available to your repository managers by following these steps: 1. Login as an administrator 2. Ensure the repository you?d like to update is selected 3. Under the ?cog? icon next to the repository name, select "Manage Groups? 4. Select ?Edit? next to the repository-managers group 5. Under ?Members can?, ensure the checkbox for "create/update top container records? is selected 6. Save Group Hopefully the ?Create? action will now be available! Thanks, Payten On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. ([email protected]<mailto:[email protected]>) wrote: I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report: ?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.? Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org<http://www.archivesspace.org/> recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks! Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected]<mailto:[email protected]> 410-704-3340 _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/2077c8ae/attachment-0001.html> ------------------------------ Message: 24 Date: Wed, 16 Nov 2016 12:45:33 +0000 From: "Joshua D. Shaw" <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Thanks, James! For the rest of the list, especially those who haven?t had a chance to work with James and the rest of the gang at HM, we?ve had nothing but great work on the customizations we?ve had done. All by way of saying that if James says they are gonna fix it? it?ll be fixed! Joshua From: <[email protected]> on behalf of James Bullen <[email protected]> Reply-To: Archivesspace Users Group <[email protected]> Date: Tuesday, November 15, 2016 at 6:17 PM To: Archivesspace Users Group <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Hi all, As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority. It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able. Cheers, James ? James Bullen Hudson Molonglo On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <[email protected]<mailto:[email protected]>> wrote: Hi all ? We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type. If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache. I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet. One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out. Best, Joshua From: <[email protected]<mailto:[email protected]>> on behalf of Jason Loeffler <[email protected]<mailto:[email protected]>> Reply-To: Archivesspace Users Group <[email protected]<mailto:[email protected]>> Date: Tuesday, November 15, 2016 at 3:25 PM To: Archivesspace Users Group <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children Hi Sally, Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree<http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in. >From the sysadmin side, Maureen Callahan at Yale commissioned Percona to >evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me >know if you need any help interpreting the report. At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements. JL On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <[email protected]<mailto:[email protected]>> wrote: Hi everyone, We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy ? it takes a couple of minutes to open any archival object in the series in edit mode and ? it takes a couple of minutes to save changes to any archival object within the series Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records? The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem. We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style? Thanks, Weatherly and Sally -- Sally Vermaaten Project Manager, Archival Systems New York University Libraries 1-212-992-6259<tel:1-212-992-6259> _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:582b7444314351074817778! _______________________________________________ Archivesspace_Users_Group mailing list [email protected]<mailto:[email protected]> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group !DSPAM:582b7444314351074817778! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bf10e9c2/attachment-0001.html> ------------------------------ Message: 25 Date: Wed, 16 Nov 2016 14:40:17 +0000 From: Yvonne Kester <[email protected]> To: Archivesspace Users Group <[email protected]> Subject: Re: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... Message-ID: <bn1pr0101mb0865718ba7101988449621a9c7...@bn1pr0101mb0865.prod.exchangelabs.com> Content-Type: text/plain; charset="utf-8" Hi Eric, We had a problem creating top containers a couple months ago. This is the answer I got from Christine: ?There is a permission that needs to be added for the permission group that your user account is part of in order for you to create top containers. See the three options for containers below; there is also one for the new location profile functionality. Have your system administrator (or someone who otherwise has privileges that allow them to manage users) add any permissions you need to your permission group. [cid:[email protected]] (There?s information about managing users and permission groups in the manual at http://docs.archivesspace.org/Default.htm#UserPermGroupsManage.htm ) I hope this helps! Yvonne From: [email protected] [mailto:[email protected]] On Behalf Of Gadsby, Eric T. Sent: Tuesday, November 15, 2016 7:47 PM To: [email protected] Subject: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers... I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report: ?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.? Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks! Sincerely, Eric T Gadsby IT Operations Specialist, Cook Library Towson University [email protected]<mailto:[email protected]> 410-704-3340 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bfbb5215/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20851 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bfbb5215/attachment.png> ------------------------------ _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group End of Archivesspace_Users_Group Digest, Vol 40, Issue 2 ******************************************************** _______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
