From epyers at slv.vic.gov.au Mon Feb 1 00:16:52 2016 From: epyers at slv.vic.gov.au (Emily Pyers) Date: Mon, 1 Feb 2016 05:16:52 +0000 Subject: [Archivesspace_Users_Group] Reporting update request In-Reply-To: <81FF938BA2407B4DA1E134E7FA5C09EC01F4FE64FB@EXMBX1.shire.nla.gov.au> References: , , <81FF938BA2407B4DA1E134E7FA5C09EC01F4FE64FB@EXMBX1.shire.nla.gov.au> Message-ID: Hi Johanna, We've just set up the ODBC connection and are using Access for our reporting (instructions are in the ArchiveSpace user documentation under 'adding a new report in ArchiveSpace'). The advantage for us in that has been that we're already using Access for our ILMS reporting, so we're already familiar with it, it's super flexible, and we can output in a variety of formats. We do lose that ability to run reports from within AS at the click of a button, but not having to familiarise ourselves with new reporting software is more of a priority for us. Cheers, Emily -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Emma Jolley Sent: Friday, 22 January 2016 9:21 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Thanks for the original question Johanna something I have been meaning to ask. So can I confirm that AS will not be creating any additional reports? Has there been anything written to members formally advising of this and providing advice on what the best way is for individual members to create reports themselves? Will the existing reports continue to be supported or will they fade out when the database is cleaned up? Many thanks Emma Emma Jolley| Curator of Digital Archives, Pictures and Manuscripts Branch|National Library of Australia Canberra ACT 2600 e: emma.jolley at nla.gov.au |t: 02 6262 1456| -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark Sent: Friday, 22 January 2016 6:12 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Thanks, Patrick! That's good to know. I've always defaulted to testing all reports with the PDF export, since I figured that was the hardest to produce, and if they didn't pass that test, they might not work at all. It's good to know that's not the case. Perhaps the PDF output option could be removed for those reports for now, unless there is a quick fix? -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Galligan, Patrick Sent: Thursday, January 21, 2016 2:06 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Mark, As for those last three reports, we've had success in running them and exporting to CSV, but not to other output formats. Still not sure what the reason is. You might want to try that. At least the data in some format is better than no data. -Patrick Galligan ________________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark [mark.custer at yale.edu] Sent: Thursday, January 21, 2016 2:03 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Hi Chris, Thanks for the examples, which are always appreciated! As to why we haven't made this particular example into a report, that reason is threefold: 1. We just (finally!) upgraded to version 1.4.2, so Jasper reports are now (almost) an option for us. 2. We don't have any reports working in our server environment just yet (and I'm outside of that work, so I'm not entirely sure what the holdup is there). I do have the Jasper reports, both packaged and custom, working fine on a local machine, though, so that roadblock should be addressed.... eventually. 3. The other reason is because I don't know of a documented way yet to pass parameters to newly-created reports. The only parameters currently passed in the reports module are contained in the last 3 reports (last in the list of reports, since I believe that these 3 reports were actually the first available in a previous release), which are run completely within ASpace, using the API to get data out, and not with Jasper, right? I also haven't heard of anyone who has those last 3 API reports set up correctly in version 1.4.2 (but I could get the Jasper reports to run fine, on a fresh, local install at least). There was another thread on the listserv about those 3 reports, but I don't know if a resolution was provided. And without being able to pass those date parameters for this specific report, we need to do run them outside of the ASpace application for the time being. I also got an error while trying to run one of those 3 API reports on test.aspace, https://urlde fense.proofpoint.com/v2/url?u=http-3A__test.archivesspace.org_jobs_30&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=TUdlB4wFHqEGYY-DBKn0He_326O-T2iYf__Z_gvKWRQ&e= , and ditto (although a different error), when trying to run things on the sandbox, https://urldefense.proofpoint.com/v2/url?u=http-3A__sandbox.archivesspace.org_reports&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=aphUJDTAUfXdX6p9yI-9I6hMosnM8FDZuS8nHDcq7f4&e= I really appreciate all of the other tips, and at some point I'll go through those examples and experiment with a few other options since I really would like to do be able to do this reporting with the API in addition to Jasper. All that said, the feedback I still keep hearing from our users, at least (and at least one other member of the Report subteam) is that they want to be able to take a query from their advanced search, and then export that data. I still see a need for more detailed, PDF-style reports for those annual reporting needs (and Jasper seems a good fit to me for that, since it's open-source), but there's also the more immediate need of the daily user - and often those users just want to get some data out of the application, quickly, for whatever reason. Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, January 21, 2016 12:02 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Hi Mark, The resources we had on the project team for reports has transitioned off the project with the expectation that the community would be creating their own reports. Jasper was seen as a primary way for doing this, but there seems to be some mixed reactions to that. So, you have the SQL query and you're comfortable using Jasper...why haven't you made this into a report? What is the road block? In regards to getting data out from the API, can do it with the aspace API (which would give you JSON) but it's also actually pretty easy to do with the Solr API. The query : https://urldefense.proofpoint.com/v2/url?u=http-3A__sandbox.archivesspace.org_advanced-5Fsearch-3Fadvanced-3Dtrue-26dop1-3Dgreater-5Fthan-26dop2-3Dlesser-5Fthan-26f0-3Dkeyword-26f1-3Dcreate-5Ftime-26f2-3Dcreate-5Ftime-26f3-3Dsuppressed-26filter-5Fterm-255B-255D-3D-257B-2522primary-5Ftype-2522-253A-2522accession-2522-257D-26op1-3DAND-26op2-3DAND-26op3-3DAND-26t0-3Dtext-26t1-3Ddate-26t2-3Ddate-26t3-3Dboolean-26v0-3Dpape-252A-26v1-3D2015-2D06-2D30-26v2-3D2016-2D07-2D01-26v3-3Dfalse&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=L9zviTzAnjAnHzH2xb3nOMWcoCst8cpDGL3y67RvYuo&e= , Essential is just passed to Solr as: https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8090_collection1_select-3Fq-3D-2528-2528-2528fullrecord-3A-2528pape-2A-2529-2BAND-2Bcreate-5Ftime-3A-5B2015-2D06-2D30T00-3A00-3A00Z-252B1DAY-2BTO-2B-2A-5D-2529-2BAND-2Bcreate-5Ftime-3A-5B-2A-2BTO-2B2016-2D07-2D01T00-3A00-3A00Z-2D1MILLISECOND-5D-2529-2BAND-2Bsuppressed-3A-2528false-2529-2529-26facet.limit-3D100-26facet.field-3Dprimary-5Ftype-26facet.field-3Dcreators-26facet.field-3Dsubjects-26start-3D0-26fq-3Drepository-3A-2522_repositories_2-2522-2BOR-2Brepository-3Aglobal-26fq-3D-2Dexclude-5Fby-5Fdefault-3Atrue-26sort-3D-26rows-3D10-26wt-3Djson-26facet-3Dtrue&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=ZjBpzXsKa2Iq5Ni8_QnxMfSyQo0xSwAxiLNu6dMxZJw&e= All you have to do is change the wt ( response format ) to csv and the rows to something like 100000. https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8090_collection1_select-3Fq-3D-2528-2528-2528fullrecord-3A-2528pape-2A-2529-2BAND-2Bcreate-5Ftime-3A-5B2015-2D06-2D30T00-3A00-3A00Z-252B1DAY-2BTO-2B-2A-5D-2529-2BAND-2Bcreate-5Ftime-3A-5B-2A-2BTO-2B2016-2D07-2D01T00-3A00-3A00Z-2D1MILLISECOND-5D-2529-2BAND-2Bsuppressed-3A-2528false-2529-2529-26facet.limit-3D100-26facet.field-3Dprimary-5Ftype-26facet.field-3Dcreators-26facet.field-3Dsubjects-26start-3D0-26fq-3Drepository-3A-2522_repositories_2-2522-2BOR-2Brepository-3Aglobal-26rows-3D10000-26wt-3Dcsv&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=DLr2t1YcduDpfXTYt9giDAyHAwz2SekgUu9kHXDe3_k&e= ( you can drop the facet stuff, since you're not needing to display that ). Solr query syntax is pretty well documented. And there's the Solr control panel that is available at port :8090 . A pro tip is to have apace running and watch the log as you submit some queries. You'll see the request go to the frontend and then see it pass to the backend api, then passed to Solr. For Solr search, the log will look like : INFO: [collection1] webapp= path=/select params={ .... Take whats in params ( it'll start with a ?q= ) and just past that into https://urldefense.proofpoint.com/v2/url?u=http-3A__your.aspace.org-3A8090_collection1_select-3Fq&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=I6J4kGz2Yg0DTOi_pEWucPw4-uG1gGACfWzMW4-RUOc&e= ...... Make sense? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.org_&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=Ukc2vbQSd6OCnzsDsc15BjjsISDJIQoIriPxJ6mgnQM&e= ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Custer, Mark > Sent: Thursday, January 21, 2016 3:06 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request Chris, Speaking as a former member of the UAC Reports subteam, we found that the most (only?) useful report for former AT users was the print-screen report. Given that, and in addition to feedback from staff here, it sounds to me like the biggest help of all for reporting would be the following: * Staff could specify what columns they would like to display in a the search result screen (and multiple dates could display as a list in a single column, whereas description from the notes table couldn't display, just like they didn't in the AT) * Staff could take any search result that they produced, like this one, https://urldefense.proofpoint.com/v2/url?u=http-3A__sandbox.archivesspace.org_advanced-5Fsearch-3Fadvanced-3Dtrue-26dop1-3Dgreater-5Fthan-26dop2-3Dlesser-5Fthan-26f0-3Dkeyword-26f1-3Dcreate-5Ftime-26f2-3Dcreate-5Ftime-26f3-3Dsuppressed-26filter-5Fterm-255B-255D-3D-257B-2522primary-5Ftype-2522-253A-2522accession-2522-257D-26op1-3DAND-26op2-3DAND-26op3-3DAND-26t0-3Dtext-26t1-3Ddate-26t2-3Ddate-26t3-3Dboolean-26v0-3Dpape-252A-26v1-3D2015-2D06-2D30-26v2-3D2016-2D07-2D01-26v3-3Dfalse&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=L9zviTzAnjAnHzH2xb3nOMWcoCst8cpDGL3y67RvYuo&e= , and then export those results as a CSV file. And let's pretend, in this case, that the user has also added columns for the Identifier and the Accession Date. Also, every page of results would need to be exported. In this example, there are just 3 results, but even if there were 3,333 results, then all of those results should be exported into a single CSV file. >From my understanding, that's the biggest user request: as a staff user, I want to select what fields display for my search results (title isn't enough), perform an advanced search, and then export my results. Right now, for our statistical reports, we just run these "reports" to get our data out with a read-only MySQL user with a few SQL scripts, like this one: select value as 'Accession type' , COUNT(*) as 'Total accessions measured in linear feet' , ROUND(SUM(extent.number), 2) as 'Linear feet' from accession left join extent on accession.id = extent.accession_id left join enumeration_value on acquisition_type_id = enumeration_value.id where (extent_type_id IN (select id from enumeration_value where LOWER(value) like '%linear%')) and repo_id = 11 #hardcoded value for now and accession.accession_date >= '20151001' #change dates as needed and accession.accession_date <= '20151231' group by acquisition_type_id; Mark P.S. All that said, I really like Jasper, actually! But until it's easy to pass in different parameters in the staff interface when running a report (date ranges, search terms, etc.), I don't think it'll be as useful to most ASpace users as being able to export all of their search results in some fashion. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, January 21, 2016 7:51 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Reporting update request I can help in regards to getting data out via the API. What are some things you're wanting to get out? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.org_&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=Ukc2vbQSd6OCnzsDsc15BjjsISDJIQoIriPxJ6mgnQM&e= ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Carll, Johanna > Sent: Wednesday, January 20, 2016 5:46 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Reporting update request Hi all As we begin the second half of the fiscal year and plan for how we will produce our end of year statistical reports, it would be useful to have an update on AS reports. Specifically, is there a timeline for when we can expect a release that includes improved functionality of the existing reports (date limiting, improved csv exports, etc.)? Also, have there been any further developments on the approach proposed in the below report from the Reports sub-group in the UAC minutes from November 5th? currently testing reports to assist features prioritization sub-team; team wants to approach reports in a different way-get data out to use in own way; Brad Westbrook will talk to programmers about getting data out via API; sub-team feels that Jasper is not user friendly-stored reports are difficult to edit or customize unless you are a programmer and difficult to write canned reports that can be used by multiple repositories Thanks Johanna Johanna Carll Archivist and Metadata Specialist Schlesinger Library Radcliffe Institute for Advanced Study Harvard University 10 Garden Street Cambridge, MA 02138 617-495-8524 jcarll at radcliffe.harvard.edu _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwIF-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=SVAYYGBs3yJOWXqmy4EyiP4JNmEbCR7aRDdgs5aA-Q8&s=Fx5a5GrjKZYnkYq7KHTqnHjaxusnU6iDkf2cf1jIt-4&e= _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group Emily Pyers | Collections Cataloguing Librarian | Storage & Digital Collection Services State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 T +61 3 8664 7368 | epyers at slv.vic.gov.au slv.vic.gov.au This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. From cspeterson at email.gwu.edu Mon Feb 1 10:13:33 2016 From: cspeterson at email.gwu.edu (Peterson, Christie) Date: Mon, 1 Feb 2016 10:13:33 -0500 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note Message-ID: Hi Brad, As Ian mentioned, this field got used in a bunch of different ways in the past (we have over 700 instances of it being used at the component level) -- mostly to hold internal-only notes about things like missing materials, materials on loan, provenance information, restriction information and lots of idiosyncratic location information. It appears that it was favored for these purposes because it appeared on the first screen you see in AT by default, though we never had a policy for using it. In other words, it's not the best-formed stuff and it isn't easily put elsewhere, but it's important and we need to migrate it. Is there any chance that the migration tool could be updated, now that there's a place for it to go in AS? Many thanks, Christie -- Christie S. Peterson University Archivist George Washington University Libraries 704H Gelman Library cspeterson at gwu.edu 202.994.3925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.westbrook at lyrasis.org Mon Feb 1 10:21:51 2016 From: brad.westbrook at lyrasis.org (Brad Westbrook) Date: Mon, 1 Feb 2016 15:21:51 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: Message-ID: Hi, Christie, Thanks for the explanation. There is no easy way right now to update the migrator, as its author Nathan Stevens is no longer associated with the ArchivesSpace project and our two current developers are unfamiliar with that code and are occupied at capacity currently. I will check with one or two other people if they could possibly update it. Have you give any thought at GWU to modifying the script to your needs? The source code is located at https://github.com/archivesspace/at-migration. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Peterson, Christie Sent: Monday, February 01, 2016 10:14 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Brad, As Ian mentioned, this field got used in a bunch of different ways in the past (we have over 700 instances of it being used at the component level) -- mostly to hold internal-only notes about things like missing materials, materials on loan, provenance information, restriction information and lots of idiosyncratic location information. It appears that it was favored for these purposes because it appeared on the first screen you see in AT by default, though we never had a policy for using it. In other words, it's not the best-formed stuff and it isn't easily put elsewhere, but it's important and we need to migrate it. Is there any chance that the migration tool could be updated, now that there's a place for it to go in AS? Many thanks, Christie -- Christie S. Peterson University Archivist George Washington University Libraries 704H Gelman Library cspeterson at gwu.edu 202.994.3925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cspeterson at email.gwu.edu Mon Feb 1 10:31:53 2016 From: cspeterson at email.gwu.edu (Peterson, Christie) Date: Mon, 1 Feb 2016 10:31:53 -0500 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: Message-ID: Hi Brad, Thanks for the quick response and explanation. We don't currently have a java developer assigned to the migration project, so modifying the script isn't within our current scope, though it's not an impossibility. We'll be looking at other options -- such as direct SQL updates -- before we go down that road. Best, Christie -- Christie S. Peterson University Archivist George Washington University Libraries 704H Gelman Library cspeterson at gwu.edu 202.994.3925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah.huffman at duke.edu Mon Feb 1 10:34:34 2016 From: noah.huffman at duke.edu (Noah Huffman) Date: Mon, 1 Feb 2016 15:34:34 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: Message-ID: Hi Christie, While not ideal, I wonder if you could move these notes over to ASpace after migration? I know Yale wrote some SQL scripts to move timestamps and records creator info from AT to ASpace post-migration. See: http://campuspress.yale.edu/yalearchivesspace/2015/05/01/keeping-timestamps-and-creator-names-from-at/ The SQL examples are here: https://github.com/YaleArchivesSpace/migrationSQL/blob/master/UpdatingAccessionAuditTrail.sql -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Monday, February 01, 2016 10:22 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi, Christie, Thanks for the explanation. There is no easy way right now to update the migrator, as its author Nathan Stevens is no longer associated with the ArchivesSpace project and our two current developers are unfamiliar with that code and are occupied at capacity currently. I will check with one or two other people if they could possibly update it. Have you give any thought at GWU to modifying the script to your needs? The source code is located at https://github.com/archivesspace/at-migration. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Peterson, Christie Sent: Monday, February 01, 2016 10:14 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Brad, As Ian mentioned, this field got used in a bunch of different ways in the past (we have over 700 instances of it being used at the component level) -- mostly to hold internal-only notes about things like missing materials, materials on loan, provenance information, restriction information and lots of idiosyncratic location information. It appears that it was favored for these purposes because it appeared on the first screen you see in AT by default, though we never had a policy for using it. In other words, it's not the best-formed stuff and it isn't easily put elsewhere, but it's important and we need to migrate it. Is there any chance that the migration tool could be updated, now that there's a place for it to go in AS? Many thanks, Christie -- Christie S. Peterson University Archivist George Washington University Libraries 704H Gelman Library cspeterson at gwu.edu 202.994.3925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cspeterson at email.gwu.edu Mon Feb 1 10:36:50 2016 From: cspeterson at email.gwu.edu (Peterson, Christie) Date: Mon, 1 Feb 2016 10:36:50 -0500 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: Message-ID: Hi Noah, Yep, that's the kind of thing we're probably going to end up doing. Many thanks! Christie -------------- next part -------------- An HTML attachment was scrubbed... URL: From maureen.callahan at yale.edu Mon Feb 1 10:42:47 2016 From: maureen.callahan at yale.edu (Callahan, Maureen) Date: Mon, 1 Feb 2016 15:42:47 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: Message-ID: <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> Hey Christie, Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there?s a choice to keep or re-assign refids ? you?re definitely going to want to keep those to help match up the components. It?s worth noting that we made those SQL updates because of mistakes in the migrator. I?m interested to know if those ever got fixed. MC > On Feb 1, 2016, at 10:36 AM, Peterson, Christie wrote: > > Hi Noah, > > Yep, that's the kind of thing we're probably going to end up doing. > > Many thanks! > > Christie > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMKX9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPWo6wDb_Hto0q8&e= From noah.huffman at duke.edu Mon Feb 1 10:52:01 2016 From: noah.huffman at duke.edu (Noah Huffman) Date: Mon, 1 Feb 2016 15:52:01 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> References: <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> Message-ID: Christie, I have a script that sort of does what Maureen suggests. Was going to mention it earlier, but it's a bit undercooked.... https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py It can read a two-column spreadsheet (as TSV) and batch add Repository Processing notes to archival objects via the API based on ref_ID values in the spreadsheet: The example above is a modified version of a script that folks at the Bentley wrote: https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py The comments in the script should help you figure out what you might need to modify. For full disclosure, I'm a Python noob, so this is probably terribly written, but I can confirm that it works for my use case. -Noah -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Callahan, Maureen Sent: Monday, February 01, 2016 10:43 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hey Christie, Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there's a choice to keep or re-assign refids - you're definitely going to want to keep those to help match up the components. It's worth noting that we made those SQL updates because of mistakes in the migrator. I'm interested to know if those ever got fixed. MC > On Feb 1, 2016, at 10:36 AM, Peterson, Christie wrote: > > Hi Noah, > > Yep, that's the kind of thing we're probably going to end up doing. > > Many thanks! > > Christie > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW > o6wDb_Hto0q8&e= _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From j at minorscience.com Mon Feb 1 12:32:16 2016 From: j at minorscience.com (Jason Loeffler) Date: Mon, 1 Feb 2016 12:32:16 -0500 Subject: [Archivesspace_Users_Group] Slate API doc Message-ID: Minor quibble regarding the API docs but is it possible to increase the width of tocify-wrapper in order to view more of the API paths? Sort of difficult to read as-is. Thanks, JL -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Mon Feb 1 13:28:42 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 1 Feb 2016 18:28:42 +0000 Subject: [Archivesspace_Users_Group] Curious! : Import Job says it failed but resources imported In-Reply-To: References: Message-ID: Just noting that I?m still seeing this phenomenon with 1.4.2 on a clean install starting with a db:nuke database and a clean archivesspace/data directory. It only seems to occur when importing a large number of EAD files in one batch. If the import is broken up into smaller batches it works as expected. ( No problems with a batch of 10 ) With a batch of 50 or more, it imports all of the guides, then attempts to import the first guide a second time, and the batch fails with an error message about duplicate ID. However, clicking on ?browse resources?, all of the EAD files appear to have been imported. In this last case, I selected 64 files, the import job lists 64 files, and I get 64 resources. Viewing the Failed background job shows 64 files. The data/shared/job_files/import_job_1/ directory contains 64 hex-renamed xml files plus output.log. /repositories/4/jobs/1 lists 64 filenames. But the log shows that after processing 64 files, it attempts to import the first one on the list again and fails. ? Steve. On Jan 12, 2016, at 5:56 PM, Majewski, Steven (sdm7g) > wrote: Very curious error observed: Trying to move 50 resources from test server to production. Same version: ArchivesSpace v1.4.2 running on all servers. Exported all 50 from test server as EAD. Imported all 50 onto another test server as initial test. Had to redo when I found that I needed to add param to export unpublished notes. But both imports completed without complaint. Attempted to repeat the same import on production server. Imports appeared to be running successfully for an uncounted number of files, but gave this error message at the end: ================================================== 54-Mss_77-1.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /revision_statement/import_42935b5d-613c-42fa-a297-d87bd61a77f3 Created: /revision_statement/import_d0d44810-bbf2-448a-803e-59e4abe479b2 Created: /revision_statement/import_b900aae8-c51e-45d6-afd3-31d8cd45b35e Created: /revision_statement/import_42b9bd89-2058-462a-9425-8b317bacb633 5. STARTED: Cleaning up 5. DONE: Cleaning up !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORT ERROR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The following errors were found: id_0 : That ID is already in use ead_id : Must be unique %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Full Error Message: Problem creating 'Papers of Frederick D. G. Ribble': id_0 That ID is already in use, ead_id Must be unique !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! However, on clicking on the Browse Resources link for that repo, it appears that all of the resources are there. Double checking on the status of that background import job shows Job Status as ?Failed? . I stopped server, deleted solr index and indexer_state files, and restarted just to be sure of consistent state. No change. Job has failed but it appears I have all 50 imported resources. The file in the error message: 54-Mss_77-1.xml, was the first file on the list of Import files in the Batch Job page. It is not listed twice in that file list, but it appears both at the start and the end of the import log, with that failure message at the end. I believe that every other time I?ve had a batch job import failure on a single file, NONE of the files are imported. ? Steve Majewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From PJFlanagan at ship.edu Mon Feb 1 14:41:16 2016 From: PJFlanagan at ship.edu (Flanagan, Patrick) Date: Mon, 1 Feb 2016 19:41:16 +0000 Subject: [Archivesspace_Users_Group] Google, etc indexing and searching Message-ID: Good afternoon, I'm relaying a question by a member of the Keystone Library Network in regards to how data in ArchivesSpace is crawled and indexed by search engines (Google, Yahoo, et. al) "Are AS records searchable via Google and other search engines down through the component level? I searched some terms on VMI's AS pages and they all came up in a Google search right at the top. However they did not have any components, they were all upper-level titles or scope and content notes. As far as you know, are AS records searchable down through the lowest levels of a finding aid?" I don't think our instances are being indexed yet, so I have no way of knowing for sure. Is there a limit to how deeply the site is indexed and if so, is there any way to influence the depth of the search? Thanks for your time, ~Patrick Flanagan KLN Applications Administrator Keystone Library Network -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Clair at du.edu Mon Feb 1 14:54:36 2016 From: Kevin.Clair at du.edu (Kevin Clair) Date: Mon, 1 Feb 2016 19:54:36 +0000 Subject: [Archivesspace_Users_Group] Google, etc indexing and searching Message-ID: <73DB3A83-5328-40F2-A318-0D4E2BD0C993@du.edu> Hello, I know that our public site is indexed, and there doesn?t seem to be a limit to how far down into a resource tree it will index, as long as the records are published. Here?s a sample search from our public site: https://www.google.com/webhp?hl=en#hl=en&q=marjorie+hornbein+site:duarchives.coalliance.org -k From: > on behalf of "Flanagan, Patrick" > Reply-To: Archivesspace Group > Date: Monday, February 1, 2016 at 12:41 PM To: Archivesspace Group > Subject: [Archivesspace_Users_Group] Google, etc indexing and searching Good afternoon, I?m relaying a question by a member of the Keystone Library Network in regards to how data in ArchivesSpace is crawled and indexed by search engines (Google, Yahoo, et. al) ?Are AS records searchable via Google and other search engines down through the component level? I searched some terms on VMI?s AS pages and they all came up in a Google search right at the top. However they did not have any components, they were all upper-level titles or scope and content notes. As far as you know, are AS records searchable down through the lowest levels of a finding aid?? I don?t think our instances are being indexed yet, so I have no way of knowing for sure. Is there a limit to how deeply the site is indexed and if so, is there any way to influence the depth of the search? Thanks for your time, ~Patrick Flanagan KLN Applications Administrator Keystone Library Network -------------- next part -------------- An HTML attachment was scrubbed... URL: From psuda1 at tulane.edu Mon Feb 1 15:26:43 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Mon, 1 Feb 2016 20:26:43 +0000 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) Message-ID: Greetings all, Is there a plugin out there for LC subject import (not just Agent/Person import)? Or, perhaps I am missing something with the LCNAF plugin. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at eservices.virginia.edu Mon Feb 1 16:07:01 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 1 Feb 2016 21:07:01 +0000 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) In-Reply-To: References: Message-ID: <5DE443A1-ECD0-4C91-8AFC-59A89369604D@eservices.virginia.edu> Just select the last option ?LCSH? in the lcnaf import plugin. ( Note however that the plugin still doesn?t properly assign Authority ID. ) ? Steve. On Feb 1, 2016, at 3:26 PM, Suda, Phillip J > wrote: Greetings all, Is there a plugin out there for LC subject import (not just Agent/Person import)? Or, perhaps I am missing something with the LCNAF plugin. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From psuda1 at tulane.edu Mon Feb 1 16:08:20 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Mon, 1 Feb 2016 21:08:20 +0000 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) In-Reply-To: <5DE443A1-ECD0-4C91-8AFC-59A89369604D@eservices.virginia.edu> References: <5DE443A1-ECD0-4C91-8AFC-59A89369604D@eservices.virginia.edu> Message-ID: I?m an idiot. Sorry all. The snake just bit me. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g) Sent: Monday, February 01, 2016 3:07 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) Just select the last option ?LCSH? in the lcnaf import plugin. ( Note however that the plugin still doesn?t properly assign Authority ID. ) ? Steve. On Feb 1, 2016, at 3:26 PM, Suda, Phillip J > wrote: Greetings all, Is there a plugin out there for LC subject import (not just Agent/Person import)? Or, perhaps I am missing something with the LCNAF plugin. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihardy at email.gwu.edu Mon Feb 1 16:37:29 2016 From: ihardy at email.gwu.edu (Hardy, Ian) Date: Mon, 1 Feb 2016 16:37:29 -0500 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: References: <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> Message-ID: Thanks Noah and Maureen, I was able to update some test repository processing notes using Noah's scripts as a starting point for interacting with the API. I think this will do the trick for us. On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman wrote: > Christie, > > I have a script that sort of does what Maureen suggests. Was going to > mention it earlier, but it's a bit undercooked.... > > > https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py > > It can read a two-column spreadsheet (as TSV) and batch add Repository > Processing notes to archival objects via the API based on ref_ID values in > the spreadsheet: > > The example above is a modified version of a script that folks at the > Bentley wrote: > > https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py > > The comments in the script should help you figure out what you might need > to modify. For full disclosure, I'm a Python noob, so this is probably > terribly written, but I can confirm that it works for my use case. > > -Noah > > -----Original Message----- > From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of > Callahan, Maureen > Sent: Monday, February 01, 2016 10:43 AM > To: Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] AT Migration problem with > repository processing note > > Hey Christie, > > Doing it now, we would probably write a script to do an update using the > API (better built-in validation, fewer opportunities to do something > stupid). During the migration, there's a choice to keep or re-assign refids > - you're definitely going to want to keep those to help match up the > components. > > It's worth noting that we made those SQL updates because of mistakes in > the migrator. I'm interested to know if those ever got fixed. > > MC > > > > On Feb 1, 2016, at 10:36 AM, Peterson, Christie < > cspeterson at email.gwu.edu> wrote: > > > > Hi Noah, > > > > Yep, that's the kind of thing we're probably going to end up doing. > > > > Many thanks! > > > > Christie > > _______________________________________________ > > Archivesspace_Users_Group mailing list > > Archivesspace_Users_Group at lyralists.lyrasis.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. > > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW > > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK > > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW > > o6wDb_Hto0q8&e= > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu helpdesk: (202) 994-8278 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.custer at yale.edu Mon Feb 1 17:10:57 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Mon, 1 Feb 2016 22:10:57 +0000 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) In-Reply-To: <5DE443A1-ECD0-4C91-8AFC-59A89369604D@eservices.virginia.edu> References: <5DE443A1-ECD0-4C91-8AFC-59A89369604D@eservices.virginia.edu> Message-ID: That?s an important point to consider! Also, the LCNAF import tool works better for personal names than it does for corporate or family names, but in all cases it still doesn?t pull in the Authority ID. It?s a great start, though, and I?d love to see ASpace connected with other thesauri in the future! And SNAC, http://socialarchive.iath.virginia.edu/snac/search, of course ? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g) Sent: Monday, February 01, 2016 4:07 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) Just select the last option ?LCSH? in the lcnaf import plugin. ( Note however that the plugin still doesn?t properly assign Authority ID. ) ? Steve. On Feb 1, 2016, at 3:26 PM, Suda, Phillip J > wrote: Greetings all, Is there a plugin out there for LC subject import (not just Agent/Person import)? Or, perhaps I am missing something with the LCNAF plugin. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From KennedyN at si.edu Tue Feb 2 13:01:54 2016 From: KennedyN at si.edu (Kennedy, Nancy) Date: Tue, 2 Feb 2016 18:01:54 +0000 Subject: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) Message-ID: <4142170736420940ACB07EE9EECDC21F31004351@si-msedag04.US.SINET.SI.EDU> Hello all, Have any other users implemented the latest AT version 16, for java8 compatibility, per https://archivesspace.atlassian.net/browse/AR-1157? While we work towards our ArchivesSpace migration, we need to be able to use the AT with java 8 to address security vulnerabilities. While the latest AT version 16 solves the ns2 namespace export issue, our EAD imports are not working correctly. Upon EAD import, note fields all end up with extraneous "

" at the start of each paragraph. Note that there is no

, which seems to result in AT dropping this data during EAD export. (AT exports these notes with empty paragraphs

). This starts to get very messy if notes are multi-paragraph or if any additional and <emph> are involved. Has anyone else seen this? Importing: <acqinfo> <head>Provenance</head> <p>The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner.</p> </acqinfo> Results in AT data field: <p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner. Which then exports as: <accessrestrict id="ref3"> <head>Provenance</head> <p/> Thanks for any insights - Nancy Nancy Kennedy EAD Coordinator Smithsonian Institution kennedyn at si.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/01af38fc/attachment.html> From j at minorscience.com Tue Feb 2 17:37:56 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 2 Feb 2016 17:37:56 -0500 Subject: [Archivesspace_Users_Group] Bulk transferring digital objects to another repository API Message-ID: <CAP4gJsUTRs4ggtL_Mg8SKk2dyPoHkWpiPOk8A5Xx=bL8eVJD4g@mail.gmail.com> I have a large volume of d.o. that I'd like to transfer to another repo. The only sane way to accomplish this appears to be via the API but I'm having a hard time understanding the correct POST method pattern for accomplishing this. Looking at the repository transfer controller <http://bit.ly/1SWxkoz>, how is the target_repo sent in the request? Can someone send an example? Many thanks, JL Jason Loeffler Technology Consultant Minor Science | Application Development & Metadata Strategy Brooklyn, New York -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/c7ef7993/attachment.html> From carlos.lemus at unlv.edu Tue Feb 2 17:46:03 2016 From: carlos.lemus at unlv.edu (Carlos Lemus) Date: Tue, 2 Feb 2016 14:46:03 -0800 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) Message-ID: <CAPsSwYqyFHhw_yaeoTsdjWpny61EYxwV8U7kC8YnhP90edjsrA@mail.gmail.com> Hello All, At the University of Nevada Las Vegas, we have been working on importing the Authority ID for agents and subjects. I saw recently that Archivesspace added the Authority ID field to the marcxml_base_map Carlos Lemus Application Programmer, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/75e13a1f/attachment.html> From carlos.lemus at unlv.edu Tue Feb 2 17:51:57 2016 From: carlos.lemus at unlv.edu (Carlos Lemus) Date: Tue, 2 Feb 2016 14:51:57 -0800 Subject: [Archivesspace_Users_Group] LCNAF plugin for subjects (not just agents/persons) In-Reply-To: <CAPsSwYqyFHhw_yaeoTsdjWpny61EYxwV8U7kC8YnhP90edjsrA@mail.gmail.com> References: <CAPsSwYqyFHhw_yaeoTsdjWpny61EYxwV8U7kC8YnhP90edjsrA@mail.gmail.com> Message-ID: <CAPsSwYr_UnURJk=WC-Az8ue5zaRPNGYKMScXKC8JknWwMaSV3g@mail.gmail.com> Sorry, here's the link https://github.com/archivesspace/archivesspace/blob/c6ad2214ff36c65d41325acb466bee16c07c7cb8/backend/app/converters/lib/marcxml_base_map.rb#L292 I don't know if they have released their commit yet, so it may depend on what version you're using. We've edited the import so the Authority ID comes in with the corresponding LOC link. (i.e. http://id.loc.gov/authorities/names/) and then changed the LCNAF plugin to use our import. Here is the importer https://github.com/l3mus/ArchivesSpace-authority-project/tree/master/unlv_importer and where most of our edits are for the LCNAF plugin. https://github.com/l3mus/ArchivesSpace-authority-project/blob/master/lcnaf/frontend/controllers/lcnaf_controller.rb#L47-L59 Carlos Lemus Application Programmer, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas On Tue, Feb 2, 2016 at 2:46 PM, Carlos Lemus <carlos.lemus at unlv.edu> wrote: > Hello All, > > At the University of Nevada Las Vegas, we have been working on importing > the Authority ID for agents and subjects. I saw recently that Archivesspace > added the Authority ID field to the marcxml_base_map > > Carlos Lemus > Application Programmer, Special Collections Technical Services > University Libraries, University of Nevada, Las Vegas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/e0a4db6c/attachment.html> From brianjhoffman at gmail.com Tue Feb 2 18:15:45 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Tue, 2 Feb 2016 18:15:45 -0500 Subject: [Archivesspace_Users_Group] Bulk transferring digital objects to another repository API In-Reply-To: <CAP4gJsUTRs4ggtL_Mg8SKk2dyPoHkWpiPOk8A5Xx=bL8eVJD4g@mail.gmail.com> References: <CAP4gJsUTRs4ggtL_Mg8SKk2dyPoHkWpiPOk8A5Xx=bL8eVJD4g@mail.gmail.com> Message-ID: <460C26C1-EE00-4CAF-9431-25B046F086EC@gmail.com> You should be able to just append it like a normal query param. So for instance to transfer accession 1 from repo 1 to repo 2: POST http://yourhost.yourdomain/repositories/1/accessions/1/transfer?target_repo=/repositories/2 <http://yourhost.yourdomain/repositories/1/accessions/1/transfer?target_repo=/repositories/2> > On Feb 2, 2016, at 5:37 PM, Jason Loeffler <j at minorscience.com> wrote: > > I have a large volume of d.o. that I'd like to transfer to another repo. The only sane way to accomplish this appears to be via the API but I'm having a hard time understanding the correct POST method pattern for accomplishing this. Looking at the repository transfer controller <http://bit.ly/1SWxkoz>, how is the target_repo sent in the request? Can someone send an example? > > Many thanks, JL > > > > Jason Loeffler > Technology Consultant > Minor Science | Application Development & Metadata Strategy > Brooklyn, New York > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/2d1a028d/attachment.html> From j at minorscience.com Tue Feb 2 18:29:46 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 2 Feb 2016 23:29:46 +0000 (UTC) Subject: [Archivesspace_Users_Group] Bulk transferring digital objects to another repository API In-Reply-To: <460C26C1-EE00-4CAF-9431-25B046F086EC@gmail.com> References: <CAP4gJsUTRs4ggtL_Mg8SKk2dyPoHkWpiPOk8A5Xx=bL8eVJD4g@mail.gmail.com> <460C26C1-EE00-4CAF-9431-25B046F086EC@gmail.com> Message-ID: <E0903B9C708FD3BF.C5A148C3-0A54-4716-8581-922A4B11640C@mail.outlook.com> Got it. Thanks, Brian. Away from my desk but would it take wildcard or an 'all' parameter or would I have to iterate over a sequence in order to move all records? On Tue, Feb 2, 2016 at 3:15 PM -0800, "Brian Hoffman" <brianjhoffman at gmail.com> wrote: You should be able to just append it like a normal query param. So for instance to transfer accession 1 from repo 1 to repo 2: POST http://yourhost.yourdomain/repositories/1/accessions/1/transfer?target_repo=/repositories/2 On Feb 2, 2016, at 5:37 PM, Jason Loeffler <j at minorscience.com> wrote: I have a large volume of d.o. that I'd like to transfer to another repo. The only sane way to accomplish this appears to be via the API but I'm having a hard time understanding the correct POST method pattern for accomplishing this. Looking at the repository transfer controller, how is the?target_repo sent in the request? Can someone send an example?? Many thanks, JL Jason LoefflerTechnology ConsultantMinor Science | Application Development & Metadata StrategyBrooklyn, New York _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160202/c9486546/attachment.html> From brianjhoffman at gmail.com Tue Feb 2 19:05:43 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Tue, 2 Feb 2016 19:05:43 -0500 Subject: [Archivesspace_Users_Group] Bulk transferring digital objects to another repository API In-Reply-To: <E0903B9C708FD3BF.C5A148C3-0A54-4716-8581-922A4B11640C@mail.outlook.com> References: <CAP4gJsUTRs4ggtL_Mg8SKk2dyPoHkWpiPOk8A5Xx=bL8eVJD4g@mail.gmail.com> <460C26C1-EE00-4CAF-9431-25B046F086EC@gmail.com> <E0903B9C708FD3BF.C5A148C3-0A54-4716-8581-922A4B11640C@mail.outlook.com> Message-ID: <A16F0182-74D6-4738-976C-E648A2B445CA@gmail.com> If you want to move all the records in a repository to another repository, you can. But if you have a subset of records to transfer you need to hit the endpoint for each transfer. You can see how this works in the unit test for the controller: https://github.com/archivesspace/archivesspace/blob/4c26d82b1b0e343b7e1aea86a11913dcf6ff5b6f/backend/spec/controller_repo_transfers_spec.rb <https://github.com/archivesspace/archivesspace/blob/4c26d82b1b0e343b7e1aea86a11913dcf6ff5b6f/backend/spec/controller_repo_transfers_spec.rb> > On Feb 2, 2016, at 6:29 PM, Jason Loeffler <j at minorscience.com> wrote: > > Got it. Thanks, Brian. Away from my desk but would it take wildcard or an 'all' parameter or would I have to iterate over a sequence in order to move all records? > > > > > > On Tue, Feb 2, 2016 at 3:15 PM -0800, "Brian Hoffman" <brianjhoffman at gmail.com <mailto:brianjhoffman at gmail.com>> wrote: > > You should be able to just append it like a normal query param. So for instance to transfer accession 1 from repo 1 to repo 2: > > POST http://yourhost.yourdomain/repositories/1/accessions/1/transfer?target_repo=/repositories/2 <http://yourhost.yourdomain/repositories/1/accessions/1/transfer?target_repo=/repositories/2> > > > >> On Feb 2, 2016, at 5:37 PM, Jason Loeffler <j at minorscience.com <mailto:j at minorscience.com>> wrote: >> >> I have a large volume of d.o. that I'd like to transfer to another repo. The only sane way to accomplish this appears to be via the API but I'm having a hard time understanding the correct POST method pattern for accomplishing this. Looking at the repository transfer controller <http://bit.ly/1SWxkoz>, how is the target_repo sent in the request? Can someone send an example? >> >> Many thanks, JL >> >> >> >> Jason Loeffler >> Technology Consultant >> Minor Science | Application Development & Metadata Strategy >> Brooklyn, New York >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > 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/20160202/3ed7cdf0/attachment.html> From mark.custer at yale.edu Wed Feb 3 08:44:04 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Wed, 3 Feb 2016 13:44:04 +0000 Subject: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) In-Reply-To: <4142170736420940ACB07EE9EECDC21F31004351@si-msedag04.US.SINET.SI.EDU> References: <4142170736420940ACB07EE9EECDC21F31004351@si-msedag04.US.SINET.SI.EDU> Message-ID: <DCB910FAD4CF9343B3E424AF5F3310252FD1055F@x10-mbx4.yu.yale.edu> Nancy, What happens when you use AT version 15 with java 8, just out of curiosity? As for the import bug in AT version 16, is this the only issue with the upgrade? If so, I remember that I used to have a horrible hack to import barcodes into the AT, which just involved running an SQL script after every import (perhaps this could be triggered easily, without changing the core code, too?) that would move the barcodes (imported in the @label attribute) to the barcode field, and then change the label field to "Mixed materials". Assuming something like that could work, you could try something like this in a test instance of the AT as a temporary workaround: UPDATE ArchDescriptionRepeatingData SET noteContent = REPLACE(noteContent, '<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">', '') WHERE noteContent LIKE '%<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">%'; The AT never stored paragraph tags in the database before, so you'd definitely want to remove those in some way (although fixing it in the application would be best, of course). I suppose if it had the closing tag it might export okay, but I wouldn't try to add those just for the sake of the exports, since you'll need to migrate the data. Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kennedy, Nancy Sent: Tuesday, February 02, 2016 1:02 PM To: 'archivesspace_users_group at lyralists.lyrasis.org' Subject: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) Hello all, Have any other users implemented the latest AT version 16, for java8 compatibility, per https://archivesspace.atlassian.net/browse/AR-1157<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1157&d=AwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=RKhZyIOCP-rCH87AMz91_Q89CrLKSfiS9bo_ojn3T_4&s=4aOProrU86-3_tlu9ynrV2M5T41DrVQwN6bIr79XWDY&e=>? While we work towards our ArchivesSpace migration, we need to be able to use the AT with java 8 to address security vulnerabilities. While the latest AT version 16 solves the ns2 namespace export issue, our EAD imports are not working correctly. Upon EAD import, note fields all end up with extraneous "<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">" at the start of each paragraph. Note that there is no </p>, which seems to result in AT dropping this data during EAD export. (AT exports these notes with empty paragraphs <p/>). This starts to get very messy if notes are multi-paragraph or if any additional <title> and <emph> are involved. Has anyone else seen this? Importing: <acqinfo> <head>Provenance</head> <p>The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner.</p> </acqinfo> Results in AT data field: <p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=AwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=RKhZyIOCP-rCH87AMz91_Q89CrLKSfiS9bo_ojn3T_4&s=bDiPBPnipPu8j-tTV-sktjwQnLZrqdBRUaI42yhJuEs&e=>">The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner. Which then exports as: <accessrestrict id="ref3"> <head>Provenance</head> <p/> Thanks for any insights - Nancy Nancy Kennedy EAD Coordinator Smithsonian Institution kennedyn at si.edu<mailto:kennedyn at si.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160203/0a41ac4e/attachment.html> From KennedyN at si.edu Wed Feb 3 11:54:51 2016 From: KennedyN at si.edu (Kennedy, Nancy) Date: Wed, 3 Feb 2016 16:54:51 +0000 Subject: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD1055F@x10-mbx4.yu.yale.edu> References: <4142170736420940ACB07EE9EECDC21F31004351@si-msedag04.US.SINET.SI.EDU> <DCB910FAD4CF9343B3E424AF5F3310252FD1055F@x10-mbx4.yu.yale.edu> Message-ID: <4142170736420940ACB07EE9EECDC21F31004F54@si-msedag04.US.SINET.SI.EDU> Hi Mark, We are considering triggers, but as you say, we'd much prefer fixing it in the application. We have a contractor looking at this and he thinks it might have something to do with JAXB? Namely that some parameters that AT passes to JAXB may be incorrect or that the JAXB version may not be compatible with java8. But, we're hoping someone might know if we're barking up the right tree. Re: what happens in v. 15, java8. We end up with problems with both EAD imports and EAD exports. 1. EAD exports add "ns2" namespace prefixes throughout. As in, <ns2:ead xsi:schemaLocation="urn:isbn:1-931666-22-9 http://www.loc.gov/ead/ead.xsd" xmlns:ns2="urn:isbn:1-931666-22-9" xmlns:ns1="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ... <ns2:acqinfo id="ref3"> <ns2:head>Provenance</ns2:head> <ns2:p>The Oscar Bluemner papers were donated in several installments ...</ns2:p> </ns2:acqinfo> ... 2. EAD imports end up with extra opening paragraph tags and with (some) ns2 prefixes. * [Both v 15 and 16 do this] with <p xmlns:ns2="urn:isbn:1-931666-22-9" xmlns:ns1="http://www.w3.org/1999/xlink"> at the opening of each paragraph. * [v 15 only] with "ns2" prefixes on Finding Aid Data tab tags such as num, date, item, language. (yet, a num within odd/p or scopecontent/p doesn't get the ns2. So perhaps archdesc is ok, but not the eadheader...? Just a guess there... Moot point for us since ATv15 java 7 and ATv16 java 8 don't do this. ) AT then drops those problem tags on export. The paragraphs all export as blank <p/>. And, for example: EAD import <langusage>Finding aid written in <language langcode="eng">English</language>.</langusage> AT user interface: Finding aid written in <ns2:language langcode="eng">English</ns2:language>. Exports as: <ns2:langusage>Finding aid written in .</ns2:langusage> Nancy Nancy Kennedy EAD Coordinator Smithsonian Institution kennedyn at si.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark Sent: Wednesday, February 03, 2016 8:44 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) Nancy, What happens when you use AT version 15 with java 8, just out of curiosity? As for the import bug in AT version 16, is this the only issue with the upgrade? If so, I remember that I used to have a horrible hack to import barcodes into the AT, which just involved running an SQL script after every import (perhaps this could be triggered easily, without changing the core code, too?) that would move the barcodes (imported in the @label attribute) to the barcode field, and then change the label field to "Mixed materials". Assuming something like that could work, you could try something like this in a test instance of the AT as a temporary workaround: UPDATE ArchDescriptionRepeatingData SET noteContent = REPLACE(noteContent, '<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">', '') WHERE noteContent LIKE '%<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">%'; The AT never stored paragraph tags in the database before, so you'd definitely want to remove those in some way (although fixing it in the application would be best, of course). I suppose if it had the closing tag it might export okay, but I wouldn't try to add those just for the sake of the exports, since you'll need to migrate the data. Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kennedy, Nancy Sent: Tuesday, February 02, 2016 1:02 PM To: 'archivesspace_users_group at lyralists.lyrasis.org' Subject: [Archivesspace_Users_Group] Archivists Toolkit incompatibility with Java 8 (AR-1157) Hello all, Have any other users implemented the latest AT version 16, for java8 compatibility, per https://archivesspace.atlassian.net/browse/AR-1157<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1157&d=AwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=RKhZyIOCP-rCH87AMz91_Q89CrLKSfiS9bo_ojn3T_4&s=4aOProrU86-3_tlu9ynrV2M5T41DrVQwN6bIr79XWDY&e=>? While we work towards our ArchivesSpace migration, we need to be able to use the AT with java 8 to address security vulnerabilities. While the latest AT version 16 solves the ns2 namespace export issue, our EAD imports are not working correctly. Upon EAD import, note fields all end up with extraneous "<p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink">" at the start of each paragraph. Note that there is no </p>, which seems to result in AT dropping this data during EAD export. (AT exports these notes with empty paragraphs <p/>). This starts to get very messy if notes are multi-paragraph or if any additional <title> and <emph> are involved. Has anyone else seen this? Importing: <acqinfo> <head>Provenance</head> <p>The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner.</p> </acqinfo> Results in AT data field: <p xmlns="urn:isbn:1-931666-22-9" xmlns:ns2="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=AwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=RKhZyIOCP-rCH87AMz91_Q89CrLKSfiS9bo_ojn3T_4&s=bDiPBPnipPu8j-tTV-sktjwQnLZrqdBRUaI42yhJuEs&e=>">The Oscar Bluemner papers were donated in several installments from 1970 to 1985 by John Davis Hatch, an art historian and close friend of Bluemner. Which then exports as: <accessrestrict id="ref3"> <head>Provenance</head> <p/> Thanks for any insights - Nancy Nancy Kennedy EAD Coordinator Smithsonian Institution kennedyn at si.edu<mailto:kennedyn at si.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160203/d92864cc/attachment.html> From ihardy at email.gwu.edu Thu Feb 4 09:50:02 2016 From: ihardy at email.gwu.edu (Hardy, Ian) Date: Thu, 4 Feb 2016 09:50:02 -0500 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: <CAC2-8t6qBrzhC-AYDecmrPG0CGiY0tnVRNSKxUvC4Yz4+6WNug@mail.gmail.com> References: <CAEjCsgz7rXemOSyTkWfP+VFqSR3bn69r-rR8kQPAP_UuEvPQ7A@mail.gmail.com> <BN1PR08MB01111A1A34F71CDEC2D139A94DE0@BN1PR08MB011.namprd08.prod.outlook.com> <BLUPR0501MB833516A134363A6CF1BF592E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAEjCsgxfvu=swAnkkcL1QgNroGfji+iUUt7Bq7k6gDLg2OrVLQ@mail.gmail.com> <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> <BLUPR0501MB833E8870C6533DC93086F90E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAC2-8t6qBrzhC-AYDecmrPG0CGiY0tnVRNSKxUvC4Yz4+6WNug@mail.gmail.com> Message-ID: <CAC2-8t4ap+LFK7ir=v5j6BibVeyR6HCW5R8RtccDaew6Upu3XQ@mail.gmail.com> Hi Noah and others, one problem we're running into in moving these repository processing notes is that there doesn't appear to be a consistent identifier shared by the toolkit ResourcesCompoenents and Aspace archival_object table. In particular the persitentIDs in toolkit are not unique in Aspace, so the Aspace migrator adds some extra characters at the end to create it's identifier, the ref_ID. Anyone have a recommended methodology for matching between the platforms? Thanks, Ian On Mon, Feb 1, 2016 at 4:37 PM, Hardy, Ian <ihardy at email.gwu.edu> wrote: > Thanks Noah and Maureen, I was able to update some test repository > processing notes using Noah's scripts as a starting point for interacting > with the API. I think this will do the trick for us. > > On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman <noah.huffman at duke.edu> > wrote: > >> Christie, >> >> I have a script that sort of does what Maureen suggests. Was going to >> mention it earlier, but it's a bit undercooked.... >> >> >> https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py >> >> It can read a two-column spreadsheet (as TSV) and batch add Repository >> Processing notes to archival objects via the API based on ref_ID values in >> the spreadsheet: >> >> The example above is a modified version of a script that folks at the >> Bentley wrote: >> >> https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py >> >> The comments in the script should help you figure out what you might need >> to modify. For full disclosure, I'm a Python noob, so this is probably >> terribly written, but I can confirm that it works for my use case. >> >> -Noah >> >> -----Original Message----- >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of >> Callahan, Maureen >> Sent: Monday, February 01, 2016 10:43 AM >> To: Archivesspace Users Group < >> archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with >> repository processing note >> >> Hey Christie, >> >> Doing it now, we would probably write a script to do an update using the >> API (better built-in validation, fewer opportunities to do something >> stupid). During the migration, there's a choice to keep or re-assign refids >> - you're definitely going to want to keep those to help match up the >> components. >> >> It's worth noting that we made those SQL updates because of mistakes in >> the migrator. I'm interested to know if those ever got fixed. >> >> MC >> >> >> > On Feb 1, 2016, at 10:36 AM, Peterson, Christie < >> cspeterson at email.gwu.edu> wrote: >> > >> > Hi Noah, >> > >> > Yep, that's the kind of thing we're probably going to end up doing. >> > >> > Many thanks! >> > >> > Christie >> > _______________________________________________ >> > Archivesspace_Users_Group mailing list >> > Archivesspace_Users_Group at lyralists.lyrasis.org >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. >> > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW >> > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK >> > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW >> > o6wDb_Hto0q8&e= >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> > > > > -- > Ian Hardy > Systems Specialist > GW Libraries > ihardy at gwu.edu <ihardy at email.gwu.edu> > helpdesk: (202) 994-8278 > -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu <ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/f188002e/attachment.html> From noah.huffman at duke.edu Thu Feb 4 11:12:18 2016 From: noah.huffman at duke.edu (Noah Huffman) Date: Thu, 4 Feb 2016 16:12:18 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: <CAC2-8t4ap+LFK7ir=v5j6BibVeyR6HCW5R8RtccDaew6Upu3XQ@mail.gmail.com> References: <CAEjCsgz7rXemOSyTkWfP+VFqSR3bn69r-rR8kQPAP_UuEvPQ7A@mail.gmail.com> <BN1PR08MB01111A1A34F71CDEC2D139A94DE0@BN1PR08MB011.namprd08.prod.outlook.com> <BLUPR0501MB833516A134363A6CF1BF592E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAEjCsgxfvu=swAnkkcL1QgNroGfji+iUUt7Bq7k6gDLg2OrVLQ@mail.gmail.com> <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> <BLUPR0501MB833E8870C6533DC93086F90E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAC2-8t6qBrzhC-AYDecmrPG0CGiY0tnVRNSKxUvC4Yz4+6WNug@mail.gmail.com> <CAC2-8t4ap+LFK7ir=v5j6BibVeyR6HCW5R8RtccDaew6Upu3XQ@mail.gmail.com> Message-ID: <BLUPR0501MB8335F65C2A8AB1B55B94361E6D10@BLUPR0501MB833.namprd05.prod.outlook.com> Hi Ian, I?m not sure I have a great solution for this? The refIDs in AT should be unique within the context of a resource and those refIDs should match the ASpace refID values before the underscore and extra characters assigned by the migarator (e.g. ?ref64? in AT becomes ?ref64_h5n? in ASpace). I wonder if you could try matching on a combination of things, like the first part of the refID before the underscore and the ResourceComponent title? These data elements are both in ATs ResourcesComponents table. There might be some false matches here if you have lots of common titles like ?Correspondence,? but if your titles are somewhat unique it might be a good strategy. Depending on how many Repository Processing notes you?re trying to move, you could also review the matches before pushing the updates to ASpace. A better strategy would be to match on the first part of the refID string and also the resource identifier (?resourceIdentifier? field in AT?s Resource table and ?identifier? field in AS?s resource table). Determining the resource identifier based on a component?s refID might require some more advanced SQL. I haven?t done this, but others on the list might have. Any ideas? -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hardy, Ian Sent: Thursday, February 04, 2016 9:50 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Noah and others, one problem we're running into in moving these repository processing notes is that there doesn't appear to be a consistent identifier shared by the toolkit ResourcesCompoenents and Aspace archival_object table. In particular the persitentIDs in toolkit are not unique in Aspace, so the Aspace migrator adds some extra characters at the end to create it's identifier, the ref_ID. Anyone have a recommended methodology for matching between the platforms? Thanks, Ian On Mon, Feb 1, 2016 at 4:37 PM, Hardy, Ian <ihardy at email.gwu.edu<mailto:ihardy at email.gwu.edu>> wrote: Thanks Noah and Maureen, I was able to update some test repository processing notes using Noah's scripts as a starting point for interacting with the API. I think this will do the trick for us. On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: Christie, I have a script that sort of does what Maureen suggests. Was going to mention it earlier, but it's a bit undercooked.... https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py It can read a two-column spreadsheet (as TSV) and batch add Repository Processing notes to archival objects via the API based on ref_ID values in the spreadsheet: The example above is a modified version of a script that folks at the Bentley wrote: https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py The comments in the script should help you figure out what you might need to modify. For full disclosure, I'm a Python noob, so this is probably terribly written, but I can confirm that it works for my use case. -Noah -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Callahan, Maureen Sent: Monday, February 01, 2016 10:43 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hey Christie, Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there's a choice to keep or re-assign refids - you're definitely going to want to keep those to help match up the components. It's worth noting that we made those SQL updates because of mistakes in the migrator. I'm interested to know if those ever got fixed. MC > On Feb 1, 2016, at 10:36 AM, Peterson, Christie <cspeterson at email.gwu.edu<mailto:cspeterson at email.gwu.edu>> wrote: > > Hi Noah, > > Yep, that's the kind of thing we're probably going to end up doing. > > Many thanks! > > Christie > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW > o6wDb_Hto0q8&e= _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/34c3e7b8/attachment.html> From christine.dibella at lyrasis.org Thu Feb 4 11:22:27 2016 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 4 Feb 2016 16:22:27 +0000 Subject: [Archivesspace_Users_Group] FW: call for planning group for ArchivesSpace Member Forum at SAA 2016 Message-ID: <SN1PR08MB196767814BB7353B5DABEF01F1D10@SN1PR08MB1967.namprd08.prod.outlook.com> Thanks to those who have volunteered so far to help with planning for this year's ArchivesSpace Member Forum. I'm getting ready to send out a message to convene the group for the first time, so I wanted to make one more call in case there are others who'd like to join us. I'd especially encourage people who work in smaller and/or nonacademic repositories to help us in shaping this program. We're aiming to keep the time commitment for all the members of the planning group as reasonable as we can, so please just drop me a line if you'd like to be involved, even if you can't or don't know if you can be at SAA this year. Thanks! Christine From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Thursday, January 28, 2016 10:17 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>; Archivesspace Member Reps <archivesspace_member_reps at lyralists.lyrasis.org>; archivesspace_tac_uac at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] call for planning group for ArchivesSpace Member Forum at SAA 2016 Hello ArchivesSpace members, Following up on last year's inaugural ArchivesSpace Members Forum, we have begun planning for the ArchivesSpace Member Forum for 2016. This event will again be held in conjunction with the SAA conference, though we're hoping to also have an online component for those who can't attend in person. We're preliminarily planning to hold it for a full day on Tuesday, August 2, at a location in Atlanta to be determined, with a program that combines workshops, unconference-type sessions, discussion groups, and program updates. Based on feedback from last year's, it will be before SAA rather than afterwards. I'm looking for a few ArchivesSpace members to assist me with developing the format and program, organizing face-to-face and online events, and, ideally, helping with logistics at the forum itself. If you're not planning to go to SAA this year, we could certainly still use help before and afterwards, but as you would imagine it's really useful to have as many people there to pitch in on the day of as we can. The overall time commitment will be less than 5 hours a month through July, plus any time spent at the forum itself. Please drop me a line if you'd like to be involved and let me know whether or not you plan to attend SAA or otherwise be in Atlanta on August 2. I'm aiming to convene a first (phone) meeting of the planning group in early February. If you need more information at this point, please just let me know. Thanks in advance! Christine Christine Di Bella Community Outreach and Support Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:image003.png at 01CE734E.FD759D30] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/0158eb09/attachment.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/20160204/0158eb09/attachment.png> From mark.custer at yale.edu Thu Feb 4 11:32:48 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Thu, 4 Feb 2016 16:32:48 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: <BLUPR0501MB8335F65C2A8AB1B55B94361E6D10@BLUPR0501MB833.namprd05.prod.outlook.com> References: <CAEjCsgz7rXemOSyTkWfP+VFqSR3bn69r-rR8kQPAP_UuEvPQ7A@mail.gmail.com> <BN1PR08MB01111A1A34F71CDEC2D139A94DE0@BN1PR08MB011.namprd08.prod.outlook.com> <BLUPR0501MB833516A134363A6CF1BF592E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAEjCsgxfvu=swAnkkcL1QgNroGfji+iUUt7Bq7k6gDLg2OrVLQ@mail.gmail.com> <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> <BLUPR0501MB833E8870C6533DC93086F90E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAC2-8t6qBrzhC-AYDecmrPG0CGiY0tnVRNSKxUvC4Yz4+6WNug@mail.gmail.com> <CAC2-8t4ap+LFK7ir=v5j6BibVeyR6HCW5R8RtccDaew6Upu3XQ@mail.gmail.com> <BLUPR0501MB8335F65C2A8AB1B55B94361E6D10@BLUPR0501MB833.namprd05.prod.outlook.com> Message-ID: <DCB910FAD4CF9343B3E424AF5F3310252FD10FED@x10-mbx4.yu.yale.edu> We had a need to do something similar as part of our migration (the migration was last year, which I only mention because my memory is a bit foggy about this now). We used the second approach that Noah described: creating match points by concatenating the resourceIdentifier + refId from the AT. With this approach, we didn?t have any false matches, because the resource identifiers have to be unique in the AT, and the reference IDs have to be unique per resource, so I?d say that?s the way to go. Here?s the function that we used for this in SQL, which someone in our IT department wrote for us in a few minutes after hearing about our need to do something recursive-like in our AT database (Thanks, Steelsen!): DELIMITER $$ DROP FUNCTION IF EXISTS `your_at_database_name_here`.`getResourceFromComponent` $$ CREATE FUNCTION `your_at_database_name_here`.`getResourceFromComponent` (GivenID INT) RETURNS VARCHAR(1024) DETERMINISTIC BEGIN DECLARE rv INT; DECLARE tp INT; DECLARE ch INT; SET tp = GivenID; /*There is no component 0 so this will be returned if first hit is top level*/ SET ch = GivenID; WHILE ch > 0 DO SELECT IFNULL(parentResourceComponentId,-1) INTO ch FROM (SELECT parentResourceComponentId FROM resourcescomponents WHERE resourceComponentId = ch) A; IF ch > 0 THEN SET tp = ch; /*Keep replacing with the next value up the tree until you hit -1 which means the parent was null*/ END IF; END WHILE; select resourceId into rv from resourcescomponents where resourceComponentId = tp; RETURN rv; END $$ DELIMITER ; With that, you can then do something like this: select getResourceFromComponent(4444); ?which will give you the AT resourceIdentifier for the resource component that has an id = 4444. Hopefully that (or a similar approach) will help, Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Thursday, February 04, 2016 11:12 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Ian, I?m not sure I have a great solution for this? The refIDs in AT should be unique within the context of a resource and those refIDs should match the ASpace refID values before the underscore and extra characters assigned by the migarator (e.g. ?ref64? in AT becomes ?ref64_h5n? in ASpace). I wonder if you could try matching on a combination of things, like the first part of the refID before the underscore and the ResourceComponent title? These data elements are both in ATs ResourcesComponents table. There might be some false matches here if you have lots of common titles like ?Correspondence,? but if your titles are somewhat unique it might be a good strategy. Depending on how many Repository Processing notes you?re trying to move, you could also review the matches before pushing the updates to ASpace. A better strategy would be to match on the first part of the refID string and also the resource identifier (?resourceIdentifier? field in AT?s Resource table and ?identifier? field in AS?s resource table). Determining the resource identifier based on a component?s refID might require some more advanced SQL. I haven?t done this, but others on the list might have. Any ideas? -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hardy, Ian Sent: Thursday, February 04, 2016 9:50 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Noah and others, one problem we're running into in moving these repository processing notes is that there doesn't appear to be a consistent identifier shared by the toolkit ResourcesCompoenents and Aspace archival_object table. In particular the persitentIDs in toolkit are not unique in Aspace, so the Aspace migrator adds some extra characters at the end to create it's identifier, the ref_ID. Anyone have a recommended methodology for matching between the platforms? Thanks, Ian On Mon, Feb 1, 2016 at 4:37 PM, Hardy, Ian <ihardy at email.gwu.edu<mailto:ihardy at email.gwu.edu>> wrote: Thanks Noah and Maureen, I was able to update some test repository processing notes using Noah's scripts as a starting point for interacting with the API. I think this will do the trick for us. On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: Christie, I have a script that sort of does what Maureen suggests. Was going to mention it earlier, but it's a bit undercooked.... https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_noahgh221_archivesspace-2Dduke-2Dscripts_blob_master_duke-5Farchival-5Fobject-5Fmetadata-5Fadder.py&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=jp009w-j5oaIIwIn_q56kxhqnS8C5zrlBnjseo8C2tc&e=> It can read a two-column spreadsheet (as TSV) and batch add Repository Processing notes to archival objects via the API based on ref_ID values in the spreadsheet: The example above is a modified version of a script that folks at the Bentley wrote: https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_djpillen_bentley-5Fscripts_blob_master_update-5Farchival-5Fobject.py&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=FcmOPa2NB0nuOlkdbcSOotdEKfi3YBlfoBIDiLhRY7A&e=> The comments in the script should help you figure out what you might need to modify. For full disclosure, I'm a Python noob, so this is probably terribly written, but I can confirm that it works for my use case. -Noah -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Callahan, Maureen Sent: Monday, February 01, 2016 10:43 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hey Christie, Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there's a choice to keep or re-assign refids - you're definitely going to want to keep those to help match up the components. It's worth noting that we made those SQL updates because of mistakes in the migrator. I'm interested to know if those ever got fixed. MC > On Feb 1, 2016, at 10:36 AM, Peterson, Christie <cspeterson at email.gwu.edu<mailto:cspeterson at email.gwu.edu>> wrote: > > Hi Noah, > > Yep, that's the kind of thing we're probably going to end up doing. > > Many thanks! > > Christie > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW > o6wDb_Hto0q8&e= _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=5IlEg6G6_5s7Hwonjt7wZtU5RGdvO4vntjYAIgV7pcU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=5IlEg6G6_5s7Hwonjt7wZtU5RGdvO4vntjYAIgV7pcU&e=> -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/06412236/attachment.html> From maureen.callahan at yale.edu Thu Feb 4 11:39:44 2016 From: maureen.callahan at yale.edu (Callahan, Maureen) Date: Thu, 4 Feb 2016 16:39:44 +0000 Subject: [Archivesspace_Users_Group] AT Migration problem with repository processing note In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD10FED@x10-mbx4.yu.yale.edu> References: <CAEjCsgz7rXemOSyTkWfP+VFqSR3bn69r-rR8kQPAP_UuEvPQ7A@mail.gmail.com> <BN1PR08MB01111A1A34F71CDEC2D139A94DE0@BN1PR08MB011.namprd08.prod.outlook.com> <BLUPR0501MB833516A134363A6CF1BF592E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAEjCsgxfvu=swAnkkcL1QgNroGfji+iUUt7Bq7k6gDLg2OrVLQ@mail.gmail.com> <75D5987B-5FA6-41DE-88E7-F9A699DE09B4@yale.edu> <BLUPR0501MB833E8870C6533DC93086F90E6DE0@BLUPR0501MB833.namprd05.prod.outlook.com> <CAC2-8t6qBrzhC-AYDecmrPG0CGiY0tnVRNSKxUvC4Yz4+6WNug@mail.gmail.com> <CAC2-8t4ap+LFK7ir=v5j6BibVeyR6HCW5R8RtccDaew6Upu3XQ@mail.gmail.com> <BLUPR0501MB8335F65C2A8AB1B55B94361E6D10@BLUPR0501MB833.namprd05.prod.outlook.com> <DCB910FAD4CF9343B3E424AF5F3310252FD10FED@x10-mbx4.yu.yale.edu> Message-ID: <6605C15D-6A77-4F37-A907-13E571718D13@yale.edu> Those stored procedures totally saved our bacon! He actually wrote a few that are very handy: https://github.com/YaleArchivesSpace/ATK_Tools Maureen On Feb 4, 2016, at 11:32 AM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: We had a need to do something similar as part of our migration (the migration was last year, which I only mention because my memory is a bit foggy about this now). We used the second approach that Noah described: creating match points by concatenating the resourceIdentifier + refId from the AT. With this approach, we didn?t have any false matches, because the resource identifiers have to be unique in the AT, and the reference IDs have to be unique per resource, so I?d say that?s the way to go. Here?s the function that we used for this in SQL, which someone in our IT department wrote for us in a few minutes after hearing about our need to do something recursive-like in our AT database (Thanks, Steelsen!): DELIMITER $$ DROP FUNCTION IF EXISTS `your_at_database_name_here`.`getResourceFromComponent` $$ CREATE FUNCTION `your_at_database_name_here`.`getResourceFromComponent` (GivenID INT) RETURNS VARCHAR(1024) DETERMINISTIC BEGIN DECLARE rv INT; DECLARE tp INT; DECLARE ch INT; SET tp = GivenID; /*There is no component 0 so this will be returned if first hit is top level*/ SET ch = GivenID; WHILE ch > 0 DO SELECT IFNULL(parentResourceComponentId,-1) INTO ch FROM (SELECT parentResourceComponentId FROM resourcescomponents WHERE resourceComponentId = ch) A; IF ch > 0 THEN SET tp = ch; /*Keep replacing with the next value up the tree until you hit -1 which means the parent was null*/ END IF; END WHILE; select resourceId into rv from resourcescomponents where resourceComponentId = tp; RETURN rv; END $$ DELIMITER ; With that, you can then do something like this: select getResourceFromComponent(4444); ?which will give you the AT resourceIdentifier for the resource component that has an id = 4444. Hopefully that (or a similar approach) will help, Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>[mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Thursday, February 04, 2016 11:12 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Ian, I?m not sure I have a great solution for this? The refIDs in AT should be unique within the context of a resource and those refIDs should match the ASpace refID values before the underscore and extra characters assigned by the migarator (e.g. ?ref64? in AT becomes ?ref64_h5n? in ASpace). I wonder if you could try matching on a combination of things, like the first part of the refID before the underscore and the ResourceComponent title? These data elements are both in ATs ResourcesComponents table. There might be some false matches here if you have lots of common titles like ?Correspondence,? but if your titles are somewhat unique it might be a good strategy. Depending on how many Repository Processing notes you?re trying to move, you could also review the matches before pushing the updates to ASpace. A better strategy would be to match on the first part of the refID string and also the resource identifier (?resourceIdentifier? field in AT?s Resource table and ?identifier? field in AS?s resource table). Determining the resource identifier based on a component?s refID might require some more advanced SQL. I haven?t done this, but others on the list might have. Any ideas? -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>[mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hardy, Ian Sent: Thursday, February 04, 2016 9:50 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hi Noah and others, one problem we're running into in moving these repository processing notes is that there doesn't appear to be a consistent identifier shared by the toolkit ResourcesCompoenents and Aspace archival_object table. In particular the persitentIDs in toolkit are not unique in Aspace, so the Aspace migrator adds some extra characters at the end to create it's identifier, the ref_ID. Anyone have a recommended methodology for matching between the platforms? Thanks, Ian On Mon, Feb 1, 2016 at 4:37 PM, Hardy, Ian <ihardy at email.gwu.edu<mailto:ihardy at email.gwu.edu>> wrote: Thanks Noah and Maureen, I was able to update some test repository processing notes using Noah's scripts as a starting point for interacting with the API. I think this will do the trick for us. On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: Christie, I have a script that sort of does what Maureen suggests. Was going to mention it earlier, but it's a bit undercooked.... https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_noahgh221_archivesspace-2Dduke-2Dscripts_blob_master_duke-5Farchival-5Fobject-5Fmetadata-5Fadder.py&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=jp009w-j5oaIIwIn_q56kxhqnS8C5zrlBnjseo8C2tc&e=> It can read a two-column spreadsheet (as TSV) and batch add Repository Processing notes to archival objects via the API based on ref_ID values in the spreadsheet: The example above is a modified version of a script that folks at the Bentley wrote: https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_djpillen_bentley-5Fscripts_blob_master_update-5Farchival-5Fobject.py&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=FcmOPa2NB0nuOlkdbcSOotdEKfi3YBlfoBIDiLhRY7A&e=> The comments in the script should help you figure out what you might need to modify. For full disclosure, I'm a Python noob, so this is probably terribly written, but I can confirm that it works for my use case. -Noah -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>[mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Callahan, Maureen Sent: Monday, February 01, 2016 10:43 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note Hey Christie, Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there's a choice to keep or re-assign refids - you're definitely going to want to keep those to help match up the components. It's worth noting that we made those SQL updates because of mistakes in the migrator. I'm interested to know if those ever got fixed. MC > On Feb 1, 2016, at 10:36 AM, Peterson, Christie <cspeterson at email.gwu.edu<mailto:cspeterson at email.gwu.edu>> wrote: > > Hi Noah, > > Yep, that's the kind of thing we're probably going to end up doing. > > Many thanks! > > Christie > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis. > org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zW > uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK > X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW > o6wDb_Hto0q8&e= _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=5IlEg6G6_5s7Hwonjt7wZtU5RGdvO4vntjYAIgV7pcU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=KdUdoHRjsxlxxbhvIQVs_HjNucajSMLTQKfZJigxEoo&s=5IlEg6G6_5s7Hwonjt7wZtU5RGdvO4vntjYAIgV7pcU&e=> -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 -- Ian Hardy Systems Specialist GW Libraries ihardy at gwu.edu<mailto:ihardy at email.gwu.edu> helpdesk: (202) 994-8278 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=DActTxziVaNijEOQhKKBKpqd3OdjlfdsbGulatIWaEQ&s=hRUvsg-SA-mqGu6ZJVTypGHc3xzngwuLItBfJPwSk6I&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/99944fb8/attachment.html> From rigginsa at uncw.edu Thu Feb 4 16:16:53 2016 From: rigginsa at uncw.edu (Riggins, Adina L.) Date: Thu, 4 Feb 2016 21:16:53 +0000 Subject: [Archivesspace_Users_Group] One Repository or Two Message-ID: <BY2PR06MB218BB4CA99C888F27E824E1A1D10@BY2PR06MB218.namprd06.prod.outlook.com> Would you please share if you selected a multi-repository implementation or one repository for your unit/institution? And why? We are trying to determine what would be best for us. We are a mid-sized university with 3 full-time staff members. 2 people work in Special Collections and 1 works in University Archives. We are physically separated due to space configurations in the library. We have similar materials (books, manuscripts, photographs, oral histories, digital collections) and similar goals, but differing collecting scopes, of course. We have different student workers. Since users can search the 2 repositories seamlessly, I don't know if it matters to the user either way? Is the primary concern, how would it affect the staff? Here are some considerations: 1. staff members would have to agree on common preferences such as default values (such as publish or not? i.e. if new records should be published by default. 2. staff members would have to share default values for things like components of identifiers and other frequently-entered data in Resource and Accession Records. If one staff member needed to deactivate the defaults, it would affect all. 3. Users may be assigned to only one repository (i.e. student workers) or to more than one. This could help limit access to certain repositories and reduce errors. 4. Would classifications get complicated if there is just 1 repository? Basically, what are your thoughts on One Repository or Two? Thank you Adina Riggins University Archivist | Randall Library University of North Carolina Wilmington 910.962.4233 rigginsa at uncw.edu | http://library.uncw.edu/archives_special/ NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. ?132-1 et seq.) and may be released to the public unless an exception applies. From mGorzalski at lib.siu.edu Thu Feb 4 17:44:40 2016 From: mGorzalski at lib.siu.edu (Matthew J Gorzalski) Date: Thu, 4 Feb 2016 22:44:40 +0000 Subject: [Archivesspace_Users_Group] bulk accessions transfer? Message-ID: <CO1PR07MB380692F1D4356E26A92F19D97D10@CO1PR07MB380.namprd07.prod.outlook.com> I've noticed some discussion on bulk transfers lately. I apologize for not following closely. Is there a way to bulk transfer accession records from one repository to another? Thanks, MATT GORZALSKI University Archivist MORRIS LIBRARY MAIL CODE 6632 SOUTHERN ILLINOIS UNIVERSITY 605 AGRICULTURE DR CARBONDALE, IL 62901 mgorzalski at lib.siu.edu P: 618/453-2225 F: 618/453-3440 lib.siu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/e4dd654d/attachment.html> From j at minorscience.com Thu Feb 4 19:23:54 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 4 Feb 2016 19:23:54 -0500 Subject: [Archivesspace_Users_Group] seeking clarification on transfer of digital objects between repositories Message-ID: <CAP4gJsWozk8Z8xR6nLxiG7zgsR2GLzHXndvKpRme+OBwbaU_hQ@mail.gmail.com> Having a little trouble understanding what's going on with transferring digital objects between repos. A repository to repository transfer of archival objects works fine. All linked digital objects are successfully transferred. However, when a resource is transferred, linked digital objects are not transferred. For testing purposes, I've created a simple hierarchy of archival objects and linked a digital object to a child item. Using both the GUI and API, I've initiated a transfer of the top-level resource to a target repository. It appears that the associated digital objects are not included in the transfer to the target repository and are orphaned at the originating repository. I am unable to use the API to transfer the orphaned digital objects to the new repository because the association between the archival object and digital object no longer exists. This is described more completely in the attached gist <https://gist.github.com/minorscience/930fd457f0815b63defd>. I posted something related here <https://archivesspace.atlassian.net/browse/AR-1405>. (Not sure if that's the right place.) Can someone confirm whether there is some design principle I am missing? Many thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/320d99e0/attachment.html> From dave_mayo at harvard.edu Fri Feb 5 10:55:12 2016 From: dave_mayo at harvard.edu (Mayo, Dave) Date: Fri, 5 Feb 2016 15:55:12 +0000 Subject: [Archivesspace_Users_Group] EAD Checking Web Application now available for general use Message-ID: <D2DA300D.F6DE%dave_mayo@harvard.edu> Hello Archivesspace user community, As of a few days ago, we here at Harvard are exposing a little web application for checking EAD files for errors that will prevent loading or produce corrupted data when trying to add EADs into Archivesspace. We don't have all the possible errors defined, but it's a starting point, and we're planning on adding all the errors we can find. At least for now, all errors are things that either stop import or produce unambiguously wrong data - and if and when we add specific local practice to the tool, I solemnly swear to make it optional. You can get output in either a custom XML format (which is basically raw schematron with some metadata wrapped around it) or as CSV. I've tested it across all our finding aids, and it should work even on fairly large and complex finding aids (we've got a 15MB one, and it passes through alright). I'm not sure if it's a concern for anyone, but we aren't capturing EADs put through the checker, except in tempfiles and memory as necessary to process them for output. We're not setting cookies, and other than apache access logs, we're collecting no information on usage. No identifying information is being collected via this tool (deliberately, at least). The tool is available here: https://eadchecker.lib.harvard.edu<http://eadchecker.lib.harvard.edu>. If you want to look at the code, or take it to customize and run on your own hardware, the code is available here: https://github.com/harvard-library/archivesspace-checker<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_harvard-2Dlibrary_archivesspace-2Dchecker&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=8hFScwJOhKpTjDm7gsD4OMearg4o5XQ76UlBTO5JUgU&s=9bl2OQLzHOED-CX_BM_iZbRE6TKP5EUtLEVgCMB5Fcc&e=>. Current docs are basically just sufficient to set it up, but continued work is planned, and contributions are welcome! The best place to leave feedback, bug reports, or feature requests is the issues queue at https://github.com/harvard-library/archivesspace-checker/issues<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_harvard-2Dlibrary_archivesspace-2Dchecker_issues&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=8hFScwJOhKpTjDm7gsD4OMearg4o5XQ76UlBTO5JUgU&s=_fg3Fd0nvM2I1TLzpbtNffzBJXthmkX5b6aKDSJtq7E&e=>, but I'm also very happy to accept any feedback or requests via email at dave_mayo at harvard.edu<mailto:dave_mayo at harvard.edu>. - Dave Mayo Library Software Engineer Harvard University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160205/ef52ab6b/attachment.html> From sdm7g at eservices.virginia.edu Fri Feb 5 14:06:23 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 5 Feb 2016 19:06:23 +0000 Subject: [Archivesspace_Users_Group] Curious! : Import Job says it failed but resources imported [SQLException: Lock wait timeout exceeded; try restarting transaction] In-Reply-To: <A844125A-DD00-4CE7-B51C-99FFBE099FAE@eservices.virginia.edu> References: <A0ECBDDB-5B07-4ACD-BB38-0762CB2E392E@eservices.virginia.edu> <A844125A-DD00-4CE7-B51C-99FFBE099FAE@eservices.virginia.edu> Message-ID: <B7BF247D-E8EE-47B1-A654-51295E9592A5@eservices.virginia.edu> More details: It appears that the job is hitting a MySQL transaction timeout. This is internal to MySQL and separate from AppConfig[:job_timeout_seconds]. Changing that AppConfig timeout has no effect on the results. This error does not occur when running against the derby demo db. It appears that that MySQL error is not causing a rollback of the transaction, and the error seems to be generated when the transaction is closed, so it appears to leave all of the resources created from that job intact. But the job is left with a ?running" status. It will eventually be relaunched as a ?stale? job on another thread. ( This is where AppConfig[:job_timeout_seconds] comes in: the only effect of increasing that value is a longer wait before the job is considered stale and relaunched. ) When the job is relaunched, it starts again with the first file, and it hits the duplicate ID error, which finally causes the status to be updated to ?failed? . From googling the errors it appears that the MySQL variable that needs to be changed is @@innodb_lock_wait_timeout. However, I haven?t tested that yet, and I?m not sure that is the way to fix this problem. I?m thinking it might be better to limit the transaction to a single file import rather than the whole job, but perhaps that is done to keep the job status locked and held by the processing thread. I guess the immediate solution is just to run smaller import jobs. But I was investigating this due to the ambiguous result: I wasn?t sure if the resources produced by the failed job should be trusted to be intact and valid, but if my interpretation above is correct, then the job has run to completion, but the job status was not updated correctly. [ extracts from the log file, with stack traces truncated and some extra debug output added to backend/app/lib/background_job_queue.rb ] [java] D, [2016-02-03T07:47:40.754000 #18042] DEBUG -- : Thread-5162: Run_Pending_Job: #<Job:0x2318025e> { [java] D, [2016-02-03T07:47:40.762000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:47:45.769000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:47:50.778000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:47:55.786000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:00.794000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:05.800000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:10.806000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:15.812000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:20.816000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:25.823000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:48:30.827000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:49:22.939000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:50:14.025000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:51:06.112000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:51:58.214000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:52:50.316000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:53:42.428000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:54:34.505000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:55:26.607000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] D, [2016-02-03T07:56:18.710000 #18042] DEBUG -- : Thread-5164: Running job Job:1 [java] E, [2016-02-03T07:58:16.577000 #18042] ERROR -- : Thread-5162: Job 1 failed: Java::JavaSql::SQLException: Lock wait timeout exceeded; try restarting transaction ["com.mysql.jdbc.SQLError.createSQLException(com/mysql/jdbc/SQLError.java:1086)", "com.mysql.jdbc.MysqlIO.checkErrorPacket(com/mysql/jdbc/MysqlIO.java:4237)", "com.mysql.jdbc.MysqlIO.checkErrorPacket(com/mysql/jdbc/MysqlIO.java:4169)", "com.mysql.jdbc.MysqlIO.sendCommand(com/mysql/jdbc/MysqlIO.java:2617)", "com.mysql.jdbc.MysqlIO.sqlQueryDirect(com/mysql/jdbc/MysqlIO.java:2778)", "com.mysql.jdbc.ConnectionImpl.execSQL(com/m [java] D, [2016-02-03T07:58:21.603000 #18042] DEBUG -- : Thread-5162: Stale_Job:#<Job:0x7a0115ee> { [java] D, [2016-02-03T07:58:21.614000 #18042] DEBUG -- : Thread-5162: Run_Pending_Job: #<Job:0x7a0115ee> { [java] D, [2016-02-03T07:58:21.616000 #18042] DEBUG -- : Thread-6580: Running job Job:1 [java] D, [2016-02-03T07:58:26.622000 #18042] DEBUG -- : Thread-6580: Running job Job:1 [java] D, [2016-02-03T07:58:31.626000 #18042] DEBUG -- : Thread-6580: Running job Job:1 [java] D, [2016-02-03T07:58:36.630000 #18042] DEBUG -- : Thread-6580: Running job Job:1 [java] D, [2016-02-03T07:58:41.633000 #18042] DEBUG -- : Thread-6580: Running job Job:1 [java] E, [2016-02-03T07:58:45.759000 #18042] ERROR -- : Thread-5162: Job 1 failed: Problem creating 'University of Virginia Hospital Executive Director's Office (HEDO) Collection': id_0 That ID is already in use, ead_id Must be unique ["/projects/Archivespace/dcs-archivesspace/build/gems/gems/sequel-4.20.0/lib/sequel/model/base.rb:1545:in `save'", "/projects/Archivespace/dcs-archivesspace/build/gems/gems/sequel-4.20.0/lib/sequel/model/base.rb:148:in `create'", "/projects/Archivespace/dcs-archivesspace/backend/app/model/ASModel_crud.rb:345:in `create_from_json'", "/projects/Archivespace/d [java] D, [2016-02-03T07:58:46.641000 #18042] DEBUG -- : Thread-5162: Completed job Job:1 On Feb 1, 2016, at 1:28 PM, Majewski, Steven (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote: Just noting that I?m still seeing this phenomenon with 1.4.2 on a clean install starting with a db:nuke database and a clean archivesspace/data directory. It only seems to occur when importing a large number of EAD files in one batch. If the import is broken up into smaller batches it works as expected. ( No problems with a batch of 10 ) With a batch of 50 or more, it imports all of the guides, then attempts to import the first guide a second time, and the batch fails with an error message about duplicate ID. However, clicking on ?browse resources?, all of the EAD files appear to have been imported. In this last case, I selected 64 files, the import job lists 64 files, and I get 64 resources. Viewing the Failed background job shows 64 files. The data/shared/job_files/import_job_1/ directory contains 64 hex-renamed xml files plus output.log. /repositories/4/jobs/1 lists 64 filenames. But the log shows that after processing 64 files, it attempts to import the first one on the list again and fails. ? Steve. On Jan 12, 2016, at 5:56 PM, Majewski, Steven (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote: Very curious error observed: Trying to move 50 resources from test server to production. Same version: ArchivesSpace v1.4.2 running on all servers. Exported all 50 from test server as EAD. Imported all 50 onto another test server as initial test. Had to redo when I found that I needed to add param to export unpublished notes. But both imports completed without complaint. Attempted to repeat the same import on production server. Imports appeared to be running successfully for an uncounted number of files, but gave this error message at the end: ================================================== 54-Mss_77-1.xml ================================================== 1. STARTED: Reading JSON records 1. DONE: Reading JSON records 2. STARTED: Validating records and checking links 2. DONE: Validating records and checking links 3. STARTED: Evaluating record relationships 3. DONE: Evaluating record relationships 4. STARTED: Saving records: cycle 1 Created: /revision_statement/import_42935b5d-613c-42fa-a297-d87bd61a77f3 Created: /revision_statement/import_d0d44810-bbf2-448a-803e-59e4abe479b2 Created: /revision_statement/import_b900aae8-c51e-45d6-afd3-31d8cd45b35e Created: /revision_statement/import_42b9bd89-2058-462a-9425-8b317bacb633 5. STARTED: Cleaning up 5. DONE: Cleaning up !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORT ERROR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The following errors were found: id_0 : That ID is already in use ead_id : Must be unique %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Full Error Message: Problem creating 'Papers of Frederick D. G. Ribble': id_0 That ID is already in use, ead_id Must be unique !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! However, on clicking on the Browse Resources link for that repo, it appears that all of the resources are there. Double checking on the status of that background import job shows Job Status as ?Failed? . I stopped server, deleted solr index and indexer_state files, and restarted just to be sure of consistent state. No change. Job has failed but it appears I have all 50 imported resources. The file in the error message: 54-Mss_77-1.xml, was the first file on the list of Import files in the Batch Job page. It is not listed twice in that file list, but it appears both at the start and the end of the import log, with that failure message at the end. I believe that every other time I?ve had a batch job import failure on a single file, NONE of the files are imported. ? Steve Majewski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160205/2283e359/attachment.html> From sdm7g at eservices.virginia.edu Fri Feb 5 16:28:16 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 5 Feb 2016 21:28:16 +0000 Subject: [Archivesspace_Users_Group] EAD encoding errors again Message-ID: <9609ADFA-4547-4188-A9EF-F43B9E4CE209@eservices.virginia.edu> Some time ago there was a thread about some encoding errors on EAD Import that seemed hard to replicate. I just ran into an example, and it appears that the encoding error does not depend at all on the encoding of the imported EAD file. The job failed with this error: Error: #<Encoding::InvalidByteSequenceError: ""\xE2"" on US-ASCII> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This was with a file encoded as UTF-8. I converted the file to US-ASCII encoding with all non-ascii characters numerically encoded. The job failed with the same error message. Only after replacing all of the numerically encoded characters with other ascii characters was I able to successfully import it. I have been able to import lots of EAD files with non-ascii unicode characters without any problems before. The persistence of this error under different encodings seems to indicate that it?s failing on some internal transformation after the file has been parsed, and the fact that I haven?t seen this problem with other files would seem to indicate that the problem is specific to the processing of a specific element. So it?s perhaps possible that the previous, hard to replicate errors were also context specific. Unfortunately, I?m seeing this problem on my largest EAD file, and it?s too large to upload to either sandbox.archivesspace.org<http://sandbox.archivesspace.org> or JIRA. I will try to isolate the cause of this error and produce a smaller test file. [ I added a JIRA ticket AR-1421 for this, as well as AR-1420 for the import timeout error in my earlier messages. ] The good news is that after replacing those non-ascii characters, the file did successfully import in a timely manner. This was the 14MB file that I previously reported as taking more than 24 hours to import. I didn?t time the operation, but it was certainly under 15-20 minutes. ? Steve Majewski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160205/0912fdb5/attachment.html> From annee at radcliffe.harvard.edu Tue Feb 9 11:58:06 2016 From: annee at radcliffe.harvard.edu (Engelhart, Anne) Date: Tue, 9 Feb 2016 16:58:06 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <518210132.1416935.1451930177538.JavaMail.zimbra@psu.edu> References: <CO2PR0601MB742FAAEB8BF9588BB86C951A51D0@CO2PR0601MB742.namprd06.prod.outlook.com> <BY2PR02MB156461F8824904C6B412738A21C0@BY2PR02MB156.namprd02.prod.outlook.com> <760688835.2090111.1447883353225.JavaMail.zimbra@psu.edu> <BN1PR08MB011496796B7A0FD5626C5D4941C0@BN1PR08MB011.namprd08.prod.outlook.com> <SN1PR0701MB17759D1BCF2CB7D7EC7FCDEB801B0@SN1PR0701MB1775.namprd07.prod.outlook.com> <CO1PR05MB490DA3772E5CF88FC0F3A4DE61B0@CO1PR05MB490.namprd05.prod.outlook.com> <C76EE5F9-64B0-4464-B79E-1750988685FD@utc.edu> <1421198437.2051638.1448488224163.JavaMail.zimbra@psu.edu> <518210132.1416935.1451930177538.JavaMail.zimbra@psu.edu> Message-ID: <BY2PR07MB14896F1A32FB785816B0B7CDE1D60@BY2PR07MB1489.namprd07.prod.outlook.com> I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521 Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image001.png at 01D16331.219F2440] Screenshot 2 [cid:image002.png at 01D16331.219F2440] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787 fax: (617) 495-8011 kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255 | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982 http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/e93d0b82/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38864 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/e93d0b82/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49510 bytes Desc: image002.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/e93d0b82/attachment-0001.png> From Polina.Ilieva at ucsf.edu Tue Feb 9 12:53:26 2016 From: Polina.Ilieva at ucsf.edu (Ilieva, Polina) Date: Tue, 9 Feb 2016 17:53:26 +0000 Subject: [Archivesspace_Users_Group] UCSF: adding members to our AS account Message-ID: <1ACE7E6C57A05C4EA9D630E4B76D00BF71DF883E@ex08.net.ucsf.edu> Hello, How can we add one more staff member to our AS account so she will be able to access ArchivesSpace Help Center and user documentation? Her name is Laura Olson, email: Laura.Olson at ucsf.edu<mailto:Laura.Olson at ucsf.edu> . Please advise. Thank you, Polina Polina E. Ilieva, CA Head of Archives and Special Collections University of California, San Francisco 530 Parnassus Avenue, Room 525 San Francisco, CA 94143-0840 e-mail: polina.ilieva at ucsf.edu<mailto:polina.ilieva at library.ucsf.edu> | tel: 415-476-1024 http://www.library.ucsf.edu/collections/archives Blog: http://blogs.library.ucsf.edu/broughttolight/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/3a8ab294/attachment.html> From l1dougherty at ucsd.edu Tue Feb 9 13:02:53 2016 From: l1dougherty at ucsd.edu (Dougherty, Laurel) Date: Tue, 9 Feb 2016 18:02:53 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Message-ID: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619 | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521 Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image001.png at 01D16320.CE4FE1E0] Screenshot 2 [cid:image002.png at 01D16320.CE4FE1E0] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787 fax: (617) 495-8011 kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255 | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982 http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/925e88d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38864 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/925e88d6/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49510 bytes Desc: image002.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/925e88d6/attachment-0001.png> From christine.dibella at lyrasis.org Tue Feb 9 13:33:35 2016 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Tue, 9 Feb 2016 18:33:35 +0000 Subject: [Archivesspace_Users_Group] UCSF: adding members to our AS account In-Reply-To: <1ACE7E6C57A05C4EA9D630E4B76D00BF71DF883E@ex08.net.ucsf.edu> References: <1ACE7E6C57A05C4EA9D630E4B76D00BF71DF883E@ex08.net.ucsf.edu> Message-ID: <SN1PR08MB1967ADF6CBD4BBD211DCB1E5F1D60@SN1PR08MB1967.namprd08.prod.outlook.com> Hi Polina, Since it looks like Laura already has an account, I'll contact the two of you directly about what's going on in this specific case, but just as a refresher for everyone, in general, institutions can add additional users to the Help Center (also known as the authentication system) by asking someone at their institution with administrator privileges in the system to add them using the instructions attached here (also available on the system). If you need assistance with the authentication system, feel free to contact me directly. Best, Christine Christine Di Bella Community Outreach and Support Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:image003.png at 01CE734E.FD759D30] From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ilieva, Polina Sent: Tuesday, February 9, 2016 12:53 PM To: archivesspace_users_group at lyralists.lyrasis.org Cc: Olson, Laura <Laura.Olson at ucsf.edu> Subject: [Archivesspace_Users_Group] UCSF: adding members to our AS account Hello, How can we add one more staff member to our AS account so she will be able to access ArchivesSpace Help Center and user documentation? Her name is Laura Olson, email: Laura.Olson at ucsf.edu<mailto:Laura.Olson at ucsf.edu> . Please advise. Thank you, Polina Polina E. Ilieva, CA Head of Archives and Special Collections University of California, San Francisco 530 Parnassus Avenue, Room 525 San Francisco, CA 94143-0840 e-mail: polina.ilieva at ucsf.edu<mailto:polina.ilieva at library.ucsf.edu> | tel: 415-476-1024 http://www.library.ucsf.edu/collections/archives Blog: http://blogs.library.ucsf.edu/broughttolight/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/e398092d/attachment.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/20160209/e398092d/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Creating and Managing ArchivesSpace Authentication Records.pdf Type: application/pdf Size: 213175 bytes Desc: Creating and Managing ArchivesSpace Authentication Records.pdf URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/e398092d/attachment.pdf> From jjones at smith.edu Tue Feb 9 15:02:25 2016 From: jjones at smith.edu (Jasmine) Date: Tue, 9 Feb 2016 15:02:25 -0500 Subject: [Archivesspace_Users_Group] Series Relaunch! | ArchivesSpace Repository Profiles Message-ID: <6A26B612-2B3C-4484-B193-AB4968B39699@smith.edu> Dear ArchivesSpace users: The SAA Collection Management Tools Roundtable Steering Committee is relaunching its Repository Profile series, where we ask users about their decision-making process, implementation strategies, and lessons learned with collection management tools. Past profile contributions may be found here: http://www2.archivists.org/groups/collection-management-tools-roundtable/repository-profiles <http://www2.archivists.org/groups/collection-management-tools-roundtable/repository-profiles>. For this round of profiles, we are asking for ArchivesSpace users to share their experiences with us. If you would like to volunteer, please get in touch with us and/or send us your responses to the repository profile questions found here: http://bit.ly/aspace-repository-profile <http://bit.ly/aspace-repository-profile>. If you have any questions or want to send in your responses, please contact Matt Gorzalski at mGorzalski at lib.siu.edu <mailto:mGorzalski at lib.siu.edu> or Jasmine Jones at jjones at smith.edu <mailto:jjones at smith.edu>. Looking forward to your participation and hearing about your experiences with ArchivesSpace! Collection Management Tools Roundtable Steering Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/72a66082/attachment.html> From mark.custer at yale.edu Tue Feb 9 15:39:59 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Tue, 9 Feb 2016 20:39:59 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems Message-ID: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user's perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to "admin" and a password set to be the same. You'll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you'll want to update that password to something else that's a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don't know if what I'm about to describe is documented anywhere else yet). If you've migrated to ArchivesSpace using the Archivists' Toolkit migration tool (and I'm pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that's equal to "asadmin". I'm not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process - and I've seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I'd like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an "asadmin" account, whether you're in production or not (the password is easy to guess, since it's the same as the default admin user's password). If you can log in that way, I'd suggest deleting that user immediately! Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/0acafa8f/attachment.html> From akroeger at unomaha.edu Tue Feb 9 15:52:06 2016 From: akroeger at unomaha.edu (Angela Kroeger) Date: Tue, 9 Feb 2016 20:52:06 +0000 Subject: [Archivesspace_Users_Group] Digital objects Message-ID: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> Greetings, fellow ArchivesSpacers, We have a spreadsheet full of digital objects (streaming videos digitized from VHS) to add to a resource record. There appear to be two ways to add them to component view: 1) Add an item-level archival object, then add a digital object as an instance on that archival object. (One-to-one correspondence between archival objects/components and digital objects.) 2) Add the digital object directly as an instance of a series-level component. (End result will be many item-level digital objects attached to a series-level component.) Some archival objects + digital objects were added to the record in a previous project. My director would prefer we do the new batch the second way, to eliminate a step, and then go back and convert those which were done the first way to match the second way. Part of the reasoning behind this is that having what appear to be two records (the archival object and the digital object) for the same thing seems to be confusing for some of our users. However, when we have multiple digital objects with the same title (i.e.: University of Nebraska at Omaha vs. University of Nebraska at Kearney Football Game) that are differentiated by date, archival objects will show the dates under components, but digital objects will NOT show the dates under instances. Example: http://unomaha-public.lyrasistechnology.org/repositories/4/archival_objects/32891 If you follow the above link, you'll see a dozen components, which are the archival objects added in the earlier project. There is one instance which I have added so far for this new project. You can see how helpful the dates are in the component list. If I convert those components to instances as my director asked, then we will have three digital objects titled "University of Nebraska at Omaha vs. University of Nebraska at Kearney Football Game" and no easy way to tell them apart without the dates. Once I add in the rest of the many, many digital objects to come, the problem will be compounded. So my first question is, is there a setting or option to make the date (from the date subrecord in the digital object) display after the title in the link to the digital object record under instances? Otherwise, we may need to add the date to the title element itself. Conversely, is there a compelling reason why we should continue doing things the old way, adding item-level components with one and only one digital object attached to each? Would having multiple item-level digital objects attached to a series-level component be likely to cause some problem down the road? Thank you! P.S. -- Peripherally related issue: When I try to add a digital object to a component, and I have to create a new digital object record uswing the "create" option right next to the input/search box, it won't let me save the new record. I have to create the digital object record separately as a standalone, and then go into the component record and link to the digital object. When searching for the digital object from the component, that list of multiple digital objects with the same title makes it difficult. Having dates display here would also be helpful. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 14676 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/1206af8c/attachment.bin> From prom at illinois.edu Tue Feb 9 16:08:39 2016 From: prom at illinois.edu (Prom, Christopher John) Date: Tue, 9 Feb 2016 21:08:39 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> Message-ID: <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/7209c36c/attachment.html> From maureen.callahan at yale.edu Tue Feb 9 16:13:22 2016 From: maureen.callahan at yale.edu (Callahan, Maureen) Date: Tue, 9 Feb 2016 21:13:22 +0000 Subject: [Archivesspace_Users_Group] Digital objects In-Reply-To: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> References: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> Message-ID: <EF74AAC3-7C6B-4BFD-8981-23A1F8E8BEFE@yale.edu> Hi Angela, We?ve been talking a lot about digital objects too, so I?m happy to see this discussion. My first take is that ArchivesSpace will definitely accommodate whichever way you want to go, but this seems to me to be more of a question governed by DACS principle 7.3 ? "Information provided at each level of description must be appropriate to that level." We?ve been thinking of the archival object as the place where description happens, regardless of format, and as instances (container or DO) to be a pointer to the thing described. By this way of thinking, I would absolutely want to associate the digital object with the archival object describing it. I can understand how the way ArchivesSpace currently displays this data could be confusing, but it?s important to remember that the decisions you make about structure and description will outlast decisions about display. I bet the folks working on the redesign for the public interface could address some of the display concerns you have. I also think that if you take all of those digital objects and put them into one series-level bucket, it?s going to take a lot of work to sort out which lower-level components describe which digital objects. You may decide to do less granular description (for instance, only describe at the series level) and associate a bunch of containers and digital objects with that series, which could be great, but I don?t know if I would do granular description and then associate the actual stuff described therein at a higher level. I?m eager to hear what others think. Maureen On Feb 9, 2016, at 3:52 PM, Angela Kroeger <akroeger at unomaha.edu<mailto:akroeger at unomaha.edu>> wrote: Greetings, fellow ArchivesSpacers, We have a spreadsheet full of digital objects (streaming videos digitized from VHS) to add to a resource record. There appear to be two ways to add them to component view: 1) Add an item-level archival object, then add a digital object as an instance on that archival object. (One-to-one correspondence between archival objects/components and digital objects.) 2) Add the digital object directly as an instance of a series-level component. (End result will be many item-level digital objects attached to a series-level component.) Some archival objects + digital objects were added to the record in a previous project. My director would prefer we do the new batch the second way, to eliminate a step, and then go back and convert those which were done the first way to match the second way. Part of the reasoning behind this is that having what appear to be two records (the archival object and the digital object) for the same thing seems to be confusing for some of our users. However, when we have multiple digital objects with the same title (i.e.: University of Nebraska at Omaha vs. University of Nebraska at Kearney Football Game) that are differentiated by date, archival objects will show the dates under components, but digital objects will NOT show the dates under instances. Example: http://unomaha-public.lyrasistechnology.org/repositories/4/archival_objects/32891 If you follow the above link, you'll see a dozen components, which are the archival objects added in the earlier project. There is one instance which I have added so far for this new project. You can see how helpful the dates are in the component list. If I convert those components to instances as my director asked, then we will have three digital objects titled "University of Nebraska at Omaha vs. University of Nebraska at Kearney Football Game" and no easy way to tell them apart without the dates. Once I add in the rest of the many, many digital objects to come, the problem will be compounded. So my first question is, is there a setting or option to make the date (from the date subrecord in the digital object) display after the title in the link to the digital object record under instances? Otherwise, we may need to add the date to the title element itself. Conversely, is there a compelling reason why we should continue doing things the old way, adding item-level components with one and only one digital object attached to each? Would having multiple item-level digital objects attached to a series-level component be likely to cause some problem down the road? Thank you! P.S. -- Peripherally related issue: When I try to add a digital object to a component, and I have to create a new digital object record uswing the ?create? option right next to the input/search box, it won?t let me save the new record. I have to create the digital object record separately as a standalone, and then go into the component record and link to the digital object. When searching for the digital object from the component, that list of multiple digital objects with the same title makes it difficult. Having dates display here would also be helpful. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=0j-NQ68MZfE4ednUOfVyvdr-l1Ho_XEbPq2amnW8ilA&s=pmLRVTS0tVxAltaNwTtDf5IlAr5YuHX3ulxyZBYI0sA&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/17ef71d7/attachment.html> From mang.sun at rice.edu Tue Feb 9 16:42:52 2016 From: mang.sun at rice.edu (Mang Sun) Date: Tue, 9 Feb 2016 15:42:52 -0600 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> Message-ID: <56BA5D5C.2060405@rice.edu> Just got it fixed. Thank you. Mang Sun Rice U. On 2/9/2016 2:39 PM, Custer, Mark wrote: > > All, > > I wanted to send out a friendly reminder about admin accounts in > ArchivesSpace (and this is coming strictly from an ArchivesSpace > user?s perspective). > > As most are aware, when you install ArchivesSpace without any > configuration changes, you wind up with a single admin account in > ArchivesSpace that has a username equal to ?*admin*? and a password > set to be the same. You?ll want to change this password to something > else long before you go into production mode. For the most part, I > think that people take care of this on or around day one, but if you > can log into your ASpace application using that username and password, > you?ll want to update that password to something else that?s a lot > more secure! > > Less well known is what happens when you use the migration tool to > populate your ArchivesSpace database (I sent an email about this to > the listserv way back on May 8, 2015, but I don?t know if what I?m > about to describe is documented anywhere else yet). If you?ve > migrated to ArchivesSpace using the Archivists? Toolkit migration tool > (and I?m pretty sure this happens with the Archon tool, as well), then > another admin user will be added to your database. This admin user > will have a username that?s equal to ?*asadmin*?. I?m not actually > sure why the migration tool creates another user (or if the current > versions still do this), especially since you have to supply admin > credentials to the migration tool to run against the ASpace API, but I > know that this happened during our migration process ? and I?ve seen > this phantom admin user account in other ArchivesSpace installations, > as well. When we discovered this new user, we deleted it from our > database immediately after our final migration process. > > So, I?d like to ask everyone out there to check and see if they can > login to their own ArchivesSpace with an ?*asadmin*? account, whether > you?re in production or not (the password is easy to guess, since it?s > the same as the default admin user?s password). If you can log in > that way, I?d suggest deleting that user immediately! > > Mark > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/0ec7dc84/attachment.html> From j at minorscience.com Tue Feb 9 16:48:11 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 9 Feb 2016 16:48:11 -0500 Subject: [Archivesspace_Users_Group] Digital objects In-Reply-To: <EF74AAC3-7C6B-4BFD-8981-23A1F8E8BEFE@yale.edu> References: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> <EF74AAC3-7C6B-4BFD-8981-23A1F8E8BEFE@yale.edu> Message-ID: <CAP4gJsW00iim8H1pCszWNQeiQPAOCbUSJaoUE7BzyWDpxfq=Yg@mail.gmail.com> Angela, We chose to follow the pattern you described in option 1. We've adopted an explicit hierarchical relationship between resources, archival objects, and digital objects described here <https://gist.github.com/minorscience/cdc2ad64b8546fb36535>. Clearly a lot more opportunity for granularity in one's descriptive system and/or finding aids. I tend to agree with Maureen apropos "form following function". That said, how ArchivesSpace currently displays data is indeed problematic and I assure you the public UI initiative are open-minded about new ideas. In the meantime, we simply syndicate the data to a Drupal site via API which gives us much more freedom and control over exactly how records and displayed. Much easier for non-archivists to interpret, too. Regarding the error in your post-script, there was an issue in the AR queue here <https://archivesspace.atlassian.net/browse/AR-1314>. Though the issue has closed, feel free to record the steps you took to reproduce the bug and I'll see whether I can replicate. There's also a digital object tag in JIRA <https://archivesspace.atlassian.net/browse/AR-1377?jql=labels%20%3D%20digital_objects> . Jason Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Tue, Feb 9, 2016 at 4:13 PM, Callahan, Maureen <maureen.callahan at yale.edu > wrote: > Hi Angela, > > We?ve been talking a lot about digital objects too, so I?m happy to see > this discussion. > > My first take is that ArchivesSpace will definitely accommodate whichever > way you want to go, but this seems to me to be more of a question governed > by DACS principle 7.3 ? "Information provided at each level of description > must be appropriate to that level." We?ve been thinking of the archival > object as the place where description happens, regardless of format, and as > instances (container or DO) to be a pointer to the thing described. By this > way of thinking, I would absolutely want to associate the digital object > with the archival object describing it. > > I can understand how the way ArchivesSpace currently *displays* this data > could be confusing, but it?s important to remember that the decisions you > make about structure and description will outlast decisions about display. > I bet the folks working on the redesign for the public interface could > address some of the display concerns you have. > > I also think that if you take all of those digital objects and put them > into one series-level bucket, it?s going to take a lot of work to sort out > which lower-level components describe which digital objects. You may decide > to do less granular description (for instance, only describe at the series > level) and associate a bunch of containers and digital objects with that > series, which could be great, but I don?t know if I would do granular > description and then associate the actual stuff described therein at a > higher level. > > I?m eager to hear what others think. > > Maureen > > > On Feb 9, 2016, at 3:52 PM, Angela Kroeger <akroeger at unomaha.edu> wrote: > > Greetings, fellow ArchivesSpacers, > > We have a spreadsheet full of digital objects (streaming videos digitized > from VHS) to add to a resource record. There appear to be two ways to add > them to component view: > > 1) Add an item-level archival object, then add a digital object as an > instance on that archival object. (One-to-one correspondence between > archival objects/components and digital objects.) > > 2) Add the digital object directly as an instance of a series-level > component. (End result will be many item-level digital objects attached to > a series-level component.) > > Some archival objects + digital objects were added to the record in a > previous project. My director would prefer we do the new batch the second > way, to eliminate a step, and then go back and convert those which were > done the first way to match the second way. Part of the reasoning behind > this is that having what appear to be two records (the archival object and > the digital object) for the same thing seems to be confusing for some of > our users. > > However, when we have multiple digital objects with the same title (i.e.: > University of Nebraska at Omaha vs. University of Nebraska at Kearney > Football Game) that are differentiated by date, archival objects will show > the dates under components, but digital objects will NOT show the dates > under instances. > > Example: > > http://unomaha-public.lyrasistechnology.org/repositories/4/archival_objects/32891 > > If you follow the above link, you'll see a dozen components, which are the > archival objects added in the earlier project. There is one instance which > I have added so far for this new project. You can see how helpful the dates > are in the component list. If I convert those components to instances as my > director asked, then we will have three digital objects titled "University > of Nebraska at Omaha vs. University of Nebraska at Kearney Football Game" > and no easy way to tell them apart without the dates. Once I add in the > rest of the many, many digital objects to come, the problem will be > compounded. > > So my first question is, is there a setting or option to make the date > (from the date subrecord in the digital object) display after the title in > the link to the digital object record under instances? Otherwise, we may > need to add the date to the title element itself. > > Conversely, is there a compelling reason why we should continue doing > things the old way, adding item-level components with one and only one > digital object attached to each? Would having multiple item-level digital > objects attached to a series-level component be likely to cause some > problem down the road? > > Thank you! > > P.S. -- Peripherally related issue: When I try to add a digital object to > a component, and I have to create a new digital object record uswing the > ?create? option right next to the input/search box, it won?t let me save > the new record. I have to create the digital object record separately as a > standalone, and then go into the component record and link to the digital > object. When searching for the digital object from the component, that list > of multiple digital objects with the same title makes it difficult. Having > dates display here would also be helpful. > > Angela Kroeger > akroeger at unomaha.edu > Archives and Special Collections Associate > Dr. C.C. and Mabel L. Criss Library > University of Nebraska at Omaha > (402) 554-4159 > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=0j-NQ68MZfE4ednUOfVyvdr-l1Ho_XEbPq2amnW8ilA&s=pmLRVTS0tVxAltaNwTtDf5IlAr5YuHX3ulxyZBYI0sA&e= > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/cc342b0f/attachment.html> From j at minorscience.com Tue Feb 9 17:11:00 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 9 Feb 2016 17:11:00 -0500 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> Message-ID: <CAP4gJsXzg+_ipGTOZJz+QZb0UJHT7H=0ioAQ3wO4NnoTbDzPQQ@mail.gmail.com> Residing at "very small" ArchivesSpace membership level, we don't have a lot of surplus developer time. But I desperately welcome a general discussion of how security is handled at the application level, how the plugin architecture works with regard to authentication, and how to begin scoping our own SSO/SAML project. Meantime, I'm restricting access at the firewall....pretty coarse for sure. Some discussion in the source here <https://github.com/archivesspace/archivesspace/blob/4c26d82b1b0e343b7e1aea86a11913dcf6ff5b6f/backend/Authentication.md>. And there's the Dartmouth CAS plugin which looks like solid work. Lastly from the 2010 Technical Architecture Report, probably superseded by another document.... *During the technical planning meeting, nearly all attendees agreed that both a local authentication mechanism, backed by data stored in the persistence layer, was a key baseline requirement for the merged application. Additionally, attendees clearly stated that the application needs an abstracted, pluggable authentication layer that allows for implementers to use a particular authentication system supported by their institution. With this in mind, much of the discussion did not focus on providing a detailed evaluation of particular authentication mechanisms. However, attendees recommended potential support for a number of authentication systems, such as the Central Authentication Service (CAS), LDAP, Pubcookie, Shibboleth, WebAuth, and OpenID. Attendees representing the perspective of information technology managers ranked IP address-based authentication as an extremely low priority. Use of a pluggable authentication mechanism would also allow implementers to create additional modules that authenticate against other single sign-on systems not supported in the merged application's initial development phases, such as institution-specific systems.* JL Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Tue, Feb 9, 2016 at 4:08 PM, Prom, Christopher John <prom at illinois.edu> wrote: > Mark, > > Thanks for bringing this up. > > I just checked and in the case of the archon migrations, the asadmin user > is not created. However, it does make a user ?aspace? and grants it full > admin rights. Even worse, you can login as that user with NO password > (i.e. field is blank). So, that one should definitely be killed off > manually or even better the migration tool should delete it when done. > > In addition, there is another problem with archon migrations, in that the > migration tool takes ALL of the existing users from archon DBs, and > migrates them into aspace as read only users with the same login, and no > password. You can then login to the app with the old users name and no > password (field is blank) and can view but not edit data. > > All of the users the migration tool create are read only?but still this is > a security problem since someone might be able to view restricted data or > find a hack to get more permissions on the DB. > > As a related question, how is security handled generally in ASpace? Is it > relying on an external security library, or bespoke code, or some > combination of the two? > > The discovery of these types of things, in all honesty, does not engender > confidence, and probably indicates the need for a thorough security audit. > While the above problems can be cleaned up after the fact, not an ideal > solution. > > Chris Prom > Univeristy of Illinois Archives > > On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu> wrote: > > All, > > > > I wanted to send out a friendly reminder about admin accounts in > ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s > perspective). > > > > As most are aware, when you install ArchivesSpace without any > configuration changes, you wind up with a single admin account in > ArchivesSpace that has a username equal to ?*admin*? and a password set > to be the same. You?ll want to change this password to something else long > before you go into production mode. For the most part, I think that people > take care of this on or around day one, but if you can log into your ASpace > application using that username and password, you?ll want to update that > password to something else that?s a lot more secure! > > > > Less well known is what happens when you use the migration tool to > populate your ArchivesSpace database (I sent an email about this to the > listserv way back on May 8, 2015, but I don?t know if what I?m about to > describe is documented anywhere else yet). If you?ve migrated to > ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty > sure this happens with the Archon tool, as well), then another admin user > will be added to your database. This admin user will have a username > that?s equal to ?*asadmin*?. I?m not actually sure why the migration > tool creates another user (or if the current versions still do this), > especially since you have to supply admin credentials to the migration tool > to run against the ASpace API, but I know that this happened during our > migration process ? and I?ve seen this phantom admin user account in other > ArchivesSpace installations, as well. When we discovered this new user, we > deleted it from our database immediately after our final migration process. > > > > So, I?d like to ask everyone out there to check and see if they can login > to their own ArchivesSpace with an ?*asadmin*? account, whether you?re in > production or not (the password is easy to guess, since it?s the same as > the default admin user?s password). If you can log in that way, I?d > suggest deleting that user immediately! > > > > Mark > > > > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/05e25522/attachment.html> From j at minorscience.com Tue Feb 9 18:03:10 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 9 Feb 2016 18:03:10 -0500 Subject: [Archivesspace_Users_Group] Fwd: seeking clarification on transfer of digital objects between repositories In-Reply-To: <CAP4gJsWozk8Z8xR6nLxiG7zgsR2GLzHXndvKpRme+OBwbaU_hQ@mail.gmail.com> References: <CAP4gJsWozk8Z8xR6nLxiG7zgsR2GLzHXndvKpRme+OBwbaU_hQ@mail.gmail.com> Message-ID: <CAP4gJsU4ZP0CDw__8keNi5ScsafM5i-j14Kog8zwsa4MP6WZQw@mail.gmail.com> Pursuant to AR-1405 <https://archivesspace.atlassian.net/browse/AR-1405>, can anyone replicate the issue or otherwise assist in this matter? In summary, during a resource-to-repository transfer, attached digital object instances are not transferred to new repository. Thanks, Jason ---------- Forwarded message ---------- From: Jason Loeffler <j at minorscience.com> Date: Thu, Feb 4, 2016 at 7:23 PM Subject: seeking clarification on transfer of digital objects between repositories To: Archivesspace Users Group < archivesspace_users_group at lyralists.lyrasis.org> Having a little trouble understanding what's going on with transferring digital objects between repos. A repository to repository transfer of archival objects works fine. All linked digital objects are successfully transferred. However, when a resource is transferred, linked digital objects are not transferred. For testing purposes, I've created a simple hierarchy of archival objects and linked a digital object to a child item. Using both the GUI and API, I've initiated a transfer of the top-level resource to a target repository. It appears that the associated digital objects are not included in the transfer to the target repository and are orphaned at the originating repository. I am unable to use the API to transfer the orphaned digital objects to the new repository because the association between the archival object and digital object no longer exists. This is described more completely in the attached gist <https://gist.github.com/minorscience/930fd457f0815b63defd>. I posted something related here <https://archivesspace.atlassian.net/browse/AR-1405>. (Not sure if that's the right place.) Can someone confirm whether there is some design principle I am missing? Many thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/6d42884a/attachment.html> From cyndi.shein at unlv.edu Tue Feb 9 18:41:43 2016 From: cyndi.shein at unlv.edu (Cyndi Shein) Date: Tue, 9 Feb 2016 15:41:43 -0800 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> Message-ID: <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu (702) 895-2223 unlvspecialcollections <https://www.facebook.com/unlvspecialcollections> On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu> wrote: > UC San Diego concurs. The experience (and resulting complications with > managing data effectively) that Anne describes below are identical to UC > San Diego?s, and we too support AS-76. > > > > *Laurel McPhee Dougherty* > > Supervisory Archivist, Special Collections & Archives Program > > UC San Diego Library | ( 858-534-5619 | * l1dougherty at ucsd.edu > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Engelhart, > Anne > *Sent:* Tuesday, February 09, 2016 8:58 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Cc:* Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu> > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to > post Harvard University?s position on AS-76. I also posted it on JIRA, > AS-76. (Here it is below.) > > > > Anne Engelhart > > Head, Collection Services > > Schlesinger Library, Radcliffe Institute > > 10 Garden St. > > Cambridge, MA 02138 > > 617.495.8521 > > > > *Restoration of processing status to collection management records in > ArchivesSpace* > > *Summary * > > Sometime during the past year, ArchivesSpace made a major change to its > functionality. > > ? It eliminated the processing status from collection management > records. > > ? The processing status and associated date were converted to > ?event? records. > > This has created several problems for archivists at Harvard who rely on > this information for workflow and reporting purposes including: > > ? The ?processing status? in all accessions migrated from the > Archivists? Toolkit (AT) for which processing statuses were assigned now > displays as ?Not specified? (see Screenshot 1). > > ? The conversion of processing status from a condition (or type) > to an event overcomplicates what was previously a fairly straightforward > piece of collection management information. > > *Detailed discussion of issues* > > There are three troubling issues associated with this change in > functionality. > > 1. The first should be important to all archives: by converting the > processing status to an event, the ArchivesSpace developers have changed > the nature of the data. A status is not equivalent to an event, although > they can be related. There is one and only one ?status? at any one time, > but there can be multiple events. Events can lead to status changes. For > example, two ?partially processed? events may or may not lead to a status > of ?processed,? because it is entirely possible that three or more > processing events might be needed to conclude that the status of the > collection is ?processed.? In addition, some statuses may have no relation > to an event. For example ?Unknown? is a possible processing status. > Finally, how does an archivist identify ?unprocessed? accessions in this > scenario? This is another ?non-event?. Are ArchivesSpace users expected to > run a report on all accessions and look for those for which there is no > ?processing? event? Since there are many possible event types, this seems > counter-productive and unnecessarily complex. > > > > 2. The second issue is perhaps unique to Harvard albeit no less > critical. The Harvard AT-to-AS migration did not create event records based > on processing status. Instead, while our back-end data has processing > status in it, these statuses are, troublingly, not visible to staff. > Instead the processing status displays as ?not specified? (Screenshot 1). > The same record in AT displays a processing status. (Screenshot 2) > > > > > > > > > > > > > > > > > > > > *Screenshot 1* > > *Screenshot 2* > > > > 3. Processing status is a critical piece of information that should > be available to archivists for reporting on their accessions. In Harvard's > current ArchivesSpace environment is that it is not possible to understand > the scope and nature of our backlogs. The staff member who discovered this > issue previously used the AT to readily determine the number of unprocessed > accessions. While attempting to gather the same information from > ArchivesSpace, the staff member found that it was not possible to achieve > the same results with existing ArchivesSpace functionality. > > > > It is essential to the Harvard University ArchivesSpace user community > that processing status be restored to its original functionality. The > restoration of processing status to collection management records would: > > ? Allow archivists to report out on backlog and processing > statistics; > > ? Assist archivists in resource allocation planning for grant > proposals and yearly projects; and > > ? Make this data currently in the back-end of ArchivesSpace > easily available to archivists > > As such, Harvard University ArchivesSpace user community supports the JIRA > ticket (AS-76) submitted by Matt Francis of Penn State Libraries. > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW > R FRANCIS > *Sent:* Monday, January 04, 2016 12:56 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Quick FYI update for anyone interested in this thread. After a couple of > off-list discussions I decided to go ahead an create a new "feature > request" ticket in JIRA requesting that the "Processing Status" field be > restored to the Collection Management sub-record. The ticket can be viewed > at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for > forgetting to submit in the form of a user story!). > > > > If there are any questions, concerns, or clarifications that I can help > with related to the request please let me know. > > > > -Matt > > > > *Matt** Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"MATTHEW R FRANCIS" <mrf22 at psu.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Wednesday, November 25, 2015 4:50:24 PM > *Subject: *Re: > [Archivesspace_Users_Group] Collection management - processing status > disappeared... > > > > Thank you Brad for your explanation for why the change occurred with the > processing status field, and thank you Kate, Noah, and Carolyn for your > additional thoughts and feedback. > > > > Based on all of the provided feedback I asked some of our staff to > work/test the new functionality while trying to consider the intent behind > the changes, our existing local workflows and collections metadata, and the > abstract "what do we consider processing status to mean". Based on this > examination of the new functionality we would like to provide the following > feedback (many of which have already been stated in this email thread): > > - In regards to "an event record allows much more information to be > associated with the event", it has been our local practice and belief that > more nuanced processing information that would help researchers and staff > better understand a finding aid/the physical collection should be recorded > in a corresponding "Processing Information" note (which is informed by our > interpretation of DACS 7.1.8). That said, we do appreciate that the event > record allows for the capturing of some metadata that would be less > relevant to researchers, and consequently a place where additional metadata > could be recorded outside of the aforementioned note field. > - After examining our "processing status" data and discussing the new > functionality, we agree with Kate's observation that "events and processing > statuses are not logical equivalents." Additionally, we also agree with > Noah's comment "that a resource or accession will always have only one > current status." > - Additionally, based on our examination, we do not believe that is > ideal or logical to separate "processing status" from collection management > records that still include: "processing priority", "processing plan", and > "processors". > - Our local workflows appear to be at a high level similar to what > Carolyn has reported, and along with the data we had already created to > take advantage of the previous functionality, we also preferred the > simplicity of the processing status being a simple drop-down selection in > the collection management records. > - Based on our local use the processing status field, along with the > current status of the ASpace tool, we found it much easier to report on > collection status and to locate appropriate collections projects for our > workers with the previous functionality over the current. > - Finally, we also echo Kate's sentiment in that we do not understand > why the new event features requires the removal of the processing status > from the collection management records and consequently wonder if there is > any reason not to have both? > > Due to the above points we are of the opinion that if the new event > features cannot be appropriately maintained while also having the > processing status functionality reside in the collection management > records, we would be in favor of a return to the previous functionality, or > a new approach that is more similar to the previous functionality. With > that said, we understand that our rationale for this request is largely > based on our local understanding of the role of the processing status > field, our local workflows, and and our existing data. Because of this we > recognize that not all ASpace members might share our perspective, and > consequently we welcome continued discussion on this subject as appropriate. > > > > Thank you again to everyone who have already participated in the > conversation, and we hope that as a community we can reach a consensus on > the best direction for us to proceed in the near future. > > > > Hope all of you have a wonderful Thanksgiving. > > > > -Matt > > > > *Matt** Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"Runyon, Carolyn" <Carolyn-Runyon at utc.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Tuesday, November 24, 2015 2:12:09 PM > *Subject: *Re: > [Archivesspace_Users_Group] Collection management - processing status > disappeared... > > > > We used the Processing Status field in the Collection Management module to > track processing of our all our Resource records. It?s a little less > complex than the data needed to populate an Event. I preferred the basic > dropdown menu offered in Collection Management because it doesn?t require > and Event Date/Time or a link it to an Agent. With legacy data, I won?t > able to link an accurate Agent or Date to my processing events, which means > I?ll have to devise some sort of input workaround for undated and anonymous > Events. > > > > One last note, when Processing Status became and Event, Event Date/Time > and Agent Links were populated, but they?re not accurate. They appear to > reflect the Agent who selected the Processing Status and the Timestamp of > when the Agent made the Processing Status selection. This means that if I > want accurate data, I?ll need to clean up this legacy data. > > > > Cheers, > > Carolyn > > > > > > > > Carolyn Runyon > Assistant Head of Collection Services and Director of Special Collections > University of Tennessee at Chattanooga Library > 615 McCallie Ave., Chattanooga, TN 37403 > Carolyn-Runyon at utc.edu, (423) 425-4503 > Dept. 6456, LIB 439D > > > > On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu> wrote: > > I tend to agree with Kate here. It seems useful to allow a resource or > accession to have lots of processing events associated with it (who did > what, when), but it also seems that a resource or accession will always > have only one current status (processed, not processed, partially > processed, etc.). > > > > Also, associated events do not display in ?edit? mode for resources or > accessions (collection management sub-records do). As a result, it?s a bit > complicated to figure out what the processing status is if you have to sort > through a long list of associated events in ?view? mode. > > > > -Noah > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Bowers, > Kate A. > *Sent:* Thursday, November 19, 2015 9:40 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > > Brad, > > Thanks for your very thorough reply! > > I think you presented this as an either/or choice. However, because > events and processing status are not logical equivalents (they may be > associated in that the status may be the result of an event, but it does > not have to be), I do not understand why adding features to the events > record requires removal of the status. I short, is there any reason not to > have both? > > Thanks again, > > Kate > > Kate Bowers > Collections Services Archivist for Metadata, Systems, and Standards > Harvard University Archives > Cambridge, Massachusetts, USA > voice: (617) 384-7787 > fax: (617) 495-8011 > kate_bowers at harvard.edu > ------------------------------ > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Brad Westbrook <brad.westbrook at lyrasis.org> > *Sent:* Wednesday, November 18, 2015 6:04:27 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Hi. > > > > Certainly it is possible and reasonable to have a discussion of how to > adjust this change in functionality to make it more satisfying and less > confusing, including reverting back to the functionality first included in > ArchivesSpace. > > > > As I recall that functionality, it consisted of the ability to link a > single collection management record to a material description record > (accession, resource, or digital object but not components for resources > and digital objects) and, further, to indicate in that collection > management record the processing status of the material being described. > Default terms were ?completed?, ?in_progress?, and ?new?, but the > controlled value list was completely configurable. So institutions could > add any terms they wanted to that list but they could only ever apply one > status term to the material being described at a given time. > > > > We removed this field from the collection management field with the > understanding such data would be better handled as event information and > with the understanding that a change in status is first an event > accomplished at a time and by an agent. We envisioned several benefits to > this change: > > > > 1) As before, an organization has complete liberty to decide what > terms it wants to use for expressing processing events and changes in > processing status, as well as for any other events an institution chooses > to track. The ?Event Event Type? list is completely configurable. > > > > 2) An event record allows much more information to be associated > with the event, including a descriptive note about the event, when the > event occurred, and who was responsible for the event. It struck us that > knowing that processing of a collection was completed on a certain date and > by a certain individual could be more useful information that know > processing was simply completed. > > > > 3) Multiple event records can be associated to the same material > description record. For instance, using event records it would be possible > to indicate when processing of material started in one event record and > when it was completed in another. > > > > 4) Multiple event records can be linked to component records. Thus > for processing projects split into parallel parts, it would be possible to > track, say, the processing progress of series. > > > > In short, our belief is that the collection management record in > conjunction with event records provides a more comprehensive and flexible > way for organizations to record collection management information. In that > relationship, the collection management record is the location for > planning?indicating processing priority, estimating processing time, > indicating processing plan(s) and processor(s), but also noting funding > source and whether rights are determined (it?s questionable whether or not > these last two should be included in the collection management > record)?while the event record is for recording completion (or not) of > processing / administrative tasks associated with the materials?acquiring a > purchase agreement, starting processing, completing processing, etc. > > > > There are requisites for this, of course: > > > > 1) Institutional policies regarding what events are to be tracked > and what event vocabulary is to be used. > > > > 2) A process for creating and sharing reports that relate material > descriptions, collection management, and events in meaningful ways. A > segment of the ArchivesSpace community has been working to develop a > reporting process, but the trajectory being taken will place the burden on > institutions to define reports (You can, btw, see a record of this effort at > https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> > (current work) and > https://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> > (past work). It was also noted in the ArchivesSpace developers meeting > last week, that information of this type would be very suitable for > displaying in a dashboard widget. Of course, institutions can already > build their own reporting and define their own reports by using report > software to extract and format data from the ArchivesSpace MySQL database. > > > > But these would be requisites for any collection management information, > supplemented or not by event information. They would be requisites for a > reversion for a return to the previous data model. > > > > Let me close with two observations to other parts of this thread: > > > > 1) The display problem that Noah noted in his comment yesterday is a > remnant of moving collection status to events. There is a bug report > requesting its correction at AR-1324 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=> > . > > > > 2) The presence of the ?Collection Management Processing Status? in > the list of controlled values is also remnant of that change. It should be > removed , unless there is a collective decision to revert. Thanks for > pointing that out, Kelly. > > > > So it would be great to hear others weigh in on this. Collection > management and event information have, as far as I know, no prevailing > models or standards that we can simply follow. The closest to such is the > de facto collection management sub-record created for accessions in the > Archivists? Toolkit, which was generalized for all top-level material > descriptions in ArchivesSpace and supplemented by the inclusion of events. > The ArchivesSpace event module is itself an extension of the PREMIS events. > > > > Best, > > > > Brad W. > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW > R FRANCIS > *Sent:* Wednesday, November 18, 2015 4:49 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > For the reasons outlined by Kate, and seconded by Glynn, we have also > found this change rather confusing, and unfortunately it has hampered our > ability to identify and report on various issues related to processing > status, including the previously mentioned backlog issue. > > > > I do not know if this is an issue that others would like revisited, but > from our perspective we would welcome a conversation on if there is better > alternative moving forward (including possibly reverting back to the > pre-v1.3 set-up). > > > > -Matt > > > > *Matt* *Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"Glynn Edwards" <gedwards at stanford.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Wednesday, November 18, 2015 11:13:44 AM > *Subject: *Re: [Archivesspace_Users_Group] > Collection management - processing status > disappeared... > > > > Hi Kate, > > We're on the same page...I too find this rather confusing. It is not > straightforward enough for tracking status of collections across holdings > easily. > > Cheers, > > Glynn > > > > Glynn Edwards > Head, Technical Services > Director, ePADD project > Special Collections > Stanford University Libraries > Stanford, CA 94305-6064 > (650) 521-2255 | gedwards at stanford.edu > > > ------------------------------ > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Bowers, Kate A. <kate_bowers at harvard.edu> > *Sent:* Tuesday, November 17, 2015 1:08 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > I am very confused. Can you explain how this is would work? How is an > archivist supposed to understand an accession?s status from one or more > associated ?events? rather than from a straightforward status? I can also > see how this would make reporting out backlogs really difficult. > > > > The reason I ask is that I can see how an event can lead to a status, but > it is entirely possible that a status may have no associated event. > Furthermore, the same type of event may lead to different statuses. > > > > In brief, status is not the same as ?event?. I can think of a couple of > examples to illustrate this: > > ? ?Unknown? can be a status, but it has no associated event > > ? ?Partially processed? can be both a status an event. However, > if one ?partially processes? an accession once, then the accession remains > partially processed. If one ?partially processes? again, it could be that > the processing has been completed and the accession?s status is now > ?processed? or it could be that the accession is still only ?partially > processed? and that additional processing events will be necessary to reach > a ?processed? status. > > > > Thanks, > > > > Kate > > > > > > *Kate Bowers* > > Collections Services Archivist for Metadata, Systems, and Standards > > Harvard University Archives > > kate_bowers at harvard.edu <megan_sniffin-marinoff at harvard.edu> > > 617.496.2713 > > voice: (617) 384-7787 > > fax: (617) 495-8011 > > web: http://nrs.harvard.edu/urn-3:hul.eresource:archives > > Twitter: @k8_bowers > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Noah > Huffman > *Sent:* Tuesday, November 17, 2015 3:01 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Hi Kelly, > > > > During a previous release (v1.3), I think Processing Status was moved from > the collection management subrecord to an Event record. Here is a JIRA > issue describing this change: > https://archivesspace.atlassian.net/browse/AR-827 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> > > > > Here are some specifics: > > Remove ?Processing Status? Collection Management sub-record > > If data is present, migrate to Event record with these settings and linked > to same record collection management sub-record is linked to: > > > > Type = ?Processing [Value in Collection Management Record for Processing > Status]? > > > > Date/Time Specifier = ?Time stamp for last modification of Collection > Management record? > > > > Label= Agent relationship > > > > Type=Single > > > > Role=Implementer > > > > Agent=ID of agent last modifying the collection management sub-record > > > > > > So, if you previously had processing status in a collection management > subrecord, you might try browsing your event records to see if you can > locate that data. > > > > Hope this helps, > > > > -Noah > > > > ================ > > Noah Huffman > > Archivist for Metadata, Systems, and Digital Records > > David M. Rubenstein Rare Book & Manuscript Library > > Duke University | 919-660-5982 > > http://library.duke.edu/rubenstein/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Kelly > Spring > *Sent:* Tuesday, November 17, 2015 2:40 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* [Archivesspace_Users_Group] Collection management - processing > status disappeared... > > > > Hello! > > > > Our Processing Status field is visible when using the Manage Controlled > Value Lists feature; but is not present when actually working within a > collection management sub-record in an accession or resource. Any tips or > advice out there? > > > > Thank you and have a great day! > > *Kelly > > > > > > > > > > Kelly Spring > > Archivist for Special Collections > > University of California, Irvine Libraries > > (949) 824-6573 > > http://special.lib.uci.edu > <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11771 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38864 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49510 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/dcdcf2ec/attachment-0001.png> From esha at nyu.edu Tue Feb 9 20:04:26 2016 From: esha at nyu.edu (Esha Datta) Date: Tue, 9 Feb 2016 20:04:26 -0500 Subject: [Archivesspace_Users_Group] archivesspace newbie questions Message-ID: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> Hi, I'm a developer with NYU's Bobst Library and am new to JRuby and ArchivesSpace. I have to write a plugin and am trying to use pry for stepping through some code. I have done some rails work before and tried to install pry by adding it to the backend/ Gemfile and then running ./scripts/jruby -S bundle install. The command ran but didn't install pry. I then tried to install it by doing the following: ./scripts/jruby -S gem install pry That installed pry but when I tried to use it in the backend by doing "binding.pry", I got an error saying it's an undefined method. If anyone has pointers as to how to use pry in this environment, I'd really appreciate it. Basically, I'm trying to figure out what certain objects have and return in order to write the plugin. Also, I will need to write tests for the plugin. Sorry, if I've missed documentation in how to write tests for the plugin and how to run them. If someone could point me to that, I'd really appreciate it. Thanks for your time. Esha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160209/f8c834be/attachment.html> From mark.custer at yale.edu Tue Feb 9 22:07:30 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Wed, 10 Feb 2016 03:07:30 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu>, <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> Message-ID: <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [archivesspace_users_group-bounces at lyralists.lyrasis.org] on behalf of Prom, Christopher John [prom at illinois.edu] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/52bb2268/attachment.html> From dave_mayo at harvard.edu Tue Feb 9 23:28:34 2016 From: dave_mayo at harvard.edu (Mayo, Dave) Date: Wed, 10 Feb 2016 04:28:34 +0000 Subject: [Archivesspace_Users_Group] archivesspace newbie questions In-Reply-To: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> References: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> Message-ID: <D2E02009.F816%dave_mayo@harvard.edu> Hi Esha, As far as running bundler, I've found that running: ./build/run bundler -Dgemfile=../backend/Gemfile from the archivesspace root directory gets the contents of that Gemfile installed properly. I'm running my devserver via `.build/run backend:devserver`. If you're doing the same, `binding.pry` STILL won't work, because the backend doesn't log directly to console, and whatever intermediate it's using (Ant? I think Ant) only does output. What I DID get working was installing the pry-remote Gem, and then doing `binding.remote_pry` and connecting from another terminal. Let me know if this works out for you, or if there's anything else I can possibly do to help. - Dave Mayo Library Software Engineer Harvard University -> HUIT -> LTS From: Esha Datta <esha at nyu.edu<mailto:esha at nyu.edu>> Reply-To: "esha at nyu.edu<mailto:esha at nyu.edu>" <esha at nyu.edu<mailto:esha at nyu.edu>>, Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Date: Tuesday, February 9, 2016 at 8:04 PM To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] archivesspace newbie questions Hi, I'm a developer with NYU's Bobst Library and am new to JRuby and ArchivesSpace. I have to write a plugin and am trying to use pry for stepping through some code. I have done some rails work before and tried to install pry by adding it to the backend/ Gemfile and then running ./scripts/jruby -S bundle install. The command ran but didn't install pry. I then tried to install it by doing the following: ./scripts/jruby -S gem install pry That installed pry but when I tried to use it in the backend by doing "binding.pry", I got an error saying it's an undefined method. If anyone has pointers as to how to use pry in this environment, I'd really appreciate it. Basically, I'm trying to figure out what certain objects have and return in order to write the plugin. Also, I will need to write tests for the plugin. Sorry, if I've missed documentation in how to write tests for the plugin and how to run them. If someone could point me to that, I'd really appreciate it. Thanks for your time. Esha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/c87ce2a4/attachment.html> From Chris.Fitzpatrick at lyrasis.org Wed Feb 10 02:47:54 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Wed, 10 Feb 2016 07:47:54 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu>, <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu>, <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> Message-ID: <BY2PR08MB0638B72B7359CDFE4DAB841FBD70@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Sure, if there are any specific questions about security, I can answer them. In regards to the migrators, those are community efforts and rely on the community to test and review their functionality. best, chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Custer, Mark <mark.custer at yale.edu> Sent: Wednesday, February 10, 2016 4:07 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [archivesspace_users_group-bounces at lyralists.lyrasis.org] on behalf of Prom, Christopher John [prom at illinois.edu] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/a9c66910/attachment.html> From prom at illinois.edu Wed Feb 10 09:32:05 2016 From: prom at illinois.edu (Prom, Christopher John) Date: Wed, 10 Feb 2016 14:32:05 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> Message-ID: <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> Thanks Mark, this is good to hear. I do think that a security review would be helpful. My concern here is not so much with the tool, as with the fact that the app allows there to be blank passwords, which makes me wonder if there are other security problems lurking somewhere. I know this issue had come up several years ago, and I thought fixed at that time, but apparently crept back in. I also second the idea of an accessibility review. On the web team we have here, we have one person dedicated to accessibility issues, and it contributes immensely to the project as a whole to have a focus on this. Chris On Feb 9, 2016, at 9:07 PM, Custer, Mark <mark.custer at YALE.EDU<mailto:mark.custer at YALE.EDU>> wrote: Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] on behalf of Prom, Christopher John [prom at illinois.edu<mailto:prom at illinois.edu>] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/f0fa5d80/attachment.html> From esha at nyu.edu Wed Feb 10 09:34:35 2016 From: esha at nyu.edu (Esha Datta) Date: Wed, 10 Feb 2016 09:34:35 -0500 Subject: [Archivesspace_Users_Group] archivesspace newbie questions In-Reply-To: <D2E02009.F816%dave_mayo@harvard.edu> References: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> <D2E02009.F816%dave_mayo@harvard.edu> Message-ID: <CAFkiWRVJN6r+m7SnWaWP5iMNd-A+pTp3P2hU3BKG1FPOPsNuwQ@mail.gmail.com> Thanks for your email. I got the gem to install as you had mentioned; however, I'm not sure how to get pry-remote to work. I see the message: [java] [pry-remote] Waiting for client on druby://127.0.0.1:9876 But, when I try to do pry-remote in the terminal, I get a bash error: command not found. I googled around trying to see how to run pry-remote within jruby and didn't find anything of value. These are the commands I tried: 1. pry-remote: Got an error: -bash: pry-remote: command not found 2. ./scripts/jruby -S pry-remote. Error: jruby: No such file or directory -- pry (LoadError) Thanks for your help! Esha On Feb 9, 2016 11:28 PM, "Mayo, Dave" <dave_mayo at harvard.edu> wrote: > Hi Esha, > > As far as running bundler, I've found that running: > > ./build/run bundler -Dgemfile=../backend/Gemfile > > from the archivesspace root directory gets the contents of that Gemfile > installed properly. > > I'm running my devserver via `.build/run backend:devserver`. If you're > doing the same, `binding.pry` STILL won't work, because the backend doesn't > log directly to console, and whatever intermediate it's using (Ant? I think > Ant) only does output. What I DID get working was installing the > pry-remote Gem, and then doing `binding.remote_pry` and connecting from > another terminal. > > Let me know if this works out for you, or if there's anything else I can > possibly do to help. > > - Dave Mayo > Library Software Engineer > Harvard University -> HUIT -> LTS > > > From: Esha Datta <esha at nyu.edu> > Reply-To: "esha at nyu.edu" <esha at nyu.edu>, Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > Date: Tuesday, February 9, 2016 at 8:04 PM > To: "archivesspace_users_group at lyralists.lyrasis.org" < > archivesspace_users_group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] archivesspace newbie questions > > > Hi, > > I'm a developer with NYU's Bobst Library and am new to JRuby and > ArchivesSpace. I have to write a plugin and am trying to use pry for > stepping through some code. I have done some rails work before and tried to > install pry by adding it to the backend/ Gemfile > and then running ./scripts/jruby -S bundle install. The command ran but > didn't install pry. I then tried to install it by doing the following: > ./scripts/jruby -S gem install pry > That installed pry but when I tried to use it in the backend by doing > "binding.pry", I got an error saying it's an undefined method. If anyone > has pointers as to how to use pry in this environment, I'd really > appreciate it. Basically, I'm trying to figure > out what certain objects have and return in order to write the plugin. > > Also, I will need to write tests for the plugin. Sorry, if I've missed > documentation in how to write tests for the plugin and how to run them. If > someone could point me to that, I'd really appreciate it. > > Thanks for your time. > > Esha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/c5f7818c/attachment.html> From psuda1 at tulane.edu Wed Feb 10 09:44:37 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 10 Feb 2016 14:44:37 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> Message-ID: <BN1PR03MB266B6F9243AA9675FB5D1C6E5D70@BN1PR03MB266.namprd03.prod.outlook.com> Chris, all: I think that the Archon-to-ArchivesSpace migration documentation could be improved. I think it needs to be made explicit that all users will be migrated from Archon to ArchivesSpace. As you and I are both on the Migration Sub-Committee, I think we could look at improving the documentation for migration (unless of course the user migration is altered). Also, I am not sure that user migration is a negative as long as users/passwords are managed. When I have migrated from Archon to ArchivesSpace, I have deleted any users that would not be needed by staff and made sure passwords were altered. With all this being said, I do agree that a discussion about security should be had. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Wednesday, February 10, 2016 8:32 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] More admins, more problems Thanks Mark, this is good to hear. I do think that a security review would be helpful. My concern here is not so much with the tool, as with the fact that the app allows there to be blank passwords, which makes me wonder if there are other security problems lurking somewhere. I know this issue had come up several years ago, and I thought fixed at that time, but apparently crept back in. I also second the idea of an accessibility review. On the web team we have here, we have one person dedicated to accessibility issues, and it contributes immensely to the project as a whole to have a focus on this. Chris On Feb 9, 2016, at 9:07 PM, Custer, Mark <mark.custer at YALE.EDU<mailto:mark.custer at YALE.EDU>> wrote: Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] on behalf of Prom, Christopher John [prom at illinois.edu<mailto:prom at illinois.edu>] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user 'aspace' and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only-but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user's perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to "admin" and a password set to be the same. You'll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you'll want to update that password to something else that's a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don't know if what I'm about to describe is documented anywhere else yet). If you've migrated to ArchivesSpace using the Archivists' Toolkit migration tool (and I'm pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that's equal to "asadmin". I'm not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process - and I've seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I'd like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an "asadmin" account, whether you're in production or not (the password is easy to guess, since it's the same as the default admin user's password). If you can log in that way, I'd suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/27a5c452/attachment.html> From sdm7g at eservices.virginia.edu Wed Feb 10 11:28:20 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 10 Feb 2016 16:28:20 +0000 Subject: [Archivesspace_Users_Group] archivesspace newbie questions In-Reply-To: <D2E02009.F816%dave_mayo@harvard.edu> References: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> <D2E02009.F816%dave_mayo@harvard.edu> Message-ID: <8C8D26E7-396E-4AC3-8AB2-C8B41281C041@eservices.virginia.edu> Thanks for the pry-remote tip, Dave. I?ve found that using ?binding.pry? from running backend:devserver does take input, but not reliably. The symptoms look to me like it?s trying to take input from more than one thread: I can get a two letter command like ?cd? or ?ls? to work, but something like ?exit? takes several tries as it does not receive all of the characters. Googling the issue finds some problems with jruby and/or MacOS readline implementation. I was going to try to find a way to hack around it with commands in .pryrc , but pry-remote looks like it may be the simpler solution. I?m also using pry directly from the console on the backend, and pry with pry-rails in the frontend along with rbenv. binding.pry and other pry functions (as well as awesome_print gem) work OK in that environment. For that, I?ve copied most of the env settings from the ArchivesSpace jirb script, but I replace the rbenv shims path with the actual path for rbenv installed jruby ? otherwise some of the ./build/run scripts endlessly loop when trying to run some tasks: PATH=$(dirname $(rbenv which gem)):$PATH # put actual programs ahead of shims... then I run one of: if [ "$1" = "backend" ] then shift export BUNDLE_GEMFILE=$BACKEND_GEMFILE bundle exec pry --no-pager -r backend/app/main.rb -r awesome_print elif [ "$1" = "frontend" ] then shift export BUNDLE_GEMFILE=$FRONTEND_GEMFILE cd frontend bundle exec rails console fi If I?m debugging one particular component rather than the whole system, sometimes it?s easier to just issue commands from the console in pry rather than use binding.pry breakpoints. ? Steve Majewski On Feb 9, 2016, at 11:28 PM, Mayo, Dave <dave_mayo at harvard.edu<mailto:dave_mayo at harvard.edu>> wrote: Hi Esha, As far as running bundler, I've found that running: ./build/run bundler -Dgemfile=../backend/Gemfile from the archivesspace root directory gets the contents of that Gemfile installed properly. I'm running my devserver via `.build/run backend:devserver`. If you're doing the same, `binding.pry` STILL won't work, because the backend doesn't log directly to console, and whatever intermediate it's using (Ant? I think Ant) only does output. What I DID get working was installing the pry-remote Gem, and then doing `binding.remote_pry` and connecting from another terminal. Let me know if this works out for you, or if there's anything else I can possibly do to help. - Dave Mayo Library Software Engineer Harvard University -> HUIT -> LTS From: Esha Datta <esha at nyu.edu<mailto:esha at nyu.edu>> Reply-To: "esha at nyu.edu<mailto:esha at nyu.edu>" <esha at nyu.edu<mailto:esha at nyu.edu>>, Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Date: Tuesday, February 9, 2016 at 8:04 PM To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] archivesspace newbie questions Hi, I'm a developer with NYU's Bobst Library and am new to JRuby and ArchivesSpace. I have to write a plugin and am trying to use pry for stepping through some code. I have done some rails work before and tried to install pry by adding it to the backend/ Gemfile and then running ./scripts/jruby -S bundle install. The command ran but didn't install pry. I then tried to install it by doing the following: ./scripts/jruby -S gem install pry That installed pry but when I tried to use it in the backend by doing "binding.pry", I got an error saying it's an undefined method. If anyone has pointers as to how to use pry in this environment, I'd really appreciate it. Basically, I'm trying to figure out what certain objects have and return in order to write the plugin. Also, I will need to write tests for the plugin. Sorry, if I've missed documentation in how to write tests for the plugin and how to run them. If someone could point me to that, I'd really appreciate it. Thanks for your time. Esha _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/b8434007/attachment.html> From michael_vandermillen at harvard.edu Wed Feb 10 11:56:05 2016 From: michael_vandermillen at harvard.edu (Vandermillen, Michael) Date: Wed, 10 Feb 2016 16:56:05 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> Message-ID: <BY2PR0701MB2104CF598DCAB96545EC9B51E7D70@BY2PR0701MB2104.namprd07.prod.outlook.com> +1 for a review of security; there ought to be some level of password strength enforced when setting up passwords. Also, we are concerned that there is no way for a user to reset her/his own password in the UI and that only an admin can do so (at least I don't think this is possible currently?). Michael From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Wednesday, February 10, 2016 9:32 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Thanks Mark, this is good to hear. I do think that a security review would be helpful. My concern here is not so much with the tool, as with the fact that the app allows there to be blank passwords, which makes me wonder if there are other security problems lurking somewhere. I know this issue had come up several years ago, and I thought fixed at that time, but apparently crept back in. I also second the idea of an accessibility review. On the web team we have here, we have one person dedicated to accessibility issues, and it contributes immensely to the project as a whole to have a focus on this. Chris On Feb 9, 2016, at 9:07 PM, Custer, Mark <mark.custer at YALE.EDU<mailto:mark.custer at YALE.EDU>> wrote: Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] on behalf of Prom, Christopher John [prom at illinois.edu<mailto:prom at illinois.edu>] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user 'aspace' and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only-but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user's perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to "admin" and a password set to be the same. You'll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you'll want to update that password to something else that's a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don't know if what I'm about to describe is documented anywhere else yet). If you've migrated to ArchivesSpace using the Archivists' Toolkit migration tool (and I'm pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that's equal to "asadmin". I'm not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process - and I've seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I'd like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an "asadmin" account, whether you're in production or not (the password is easy to guess, since it's the same as the default admin user's password). If you can log in that way, I'd suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=VrQdYlh6WQ9nrFC-sjqrXhpO3c_dIW1HO3Q189A7J80&m=uUTSPIwvrrZVu9FOTbBKtNrbqyBBuEH_wlq43FkMZCQ&s=0Kbs7kivOC2rpo-vwjXnwl7cJt_Zs-LiWwzypCKKGVo&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/767e49a2/attachment.html> From sdm7g at eservices.virginia.edu Wed Feb 10 12:01:47 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 10 Feb 2016 17:01:47 +0000 Subject: [Archivesspace_Users_Group] archivesspace newbie questions In-Reply-To: <CAFkiWRVJN6r+m7SnWaWP5iMNd-A+pTp3P2hU3BKG1FPOPsNuwQ@mail.gmail.com> References: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> <D2E02009.F816%dave_mayo@harvard.edu> <CAFkiWRVJN6r+m7SnWaWP5iMNd-A+pTp3P2hU3BKG1FPOPsNuwQ@mail.gmail.com> Message-ID: <AB853B8A-D14D-498C-BC4B-9C74168788E5@eservices.virginia.edu> The gem and binaries should be installed in the archivesspace build/gems directory, but ./build/gems/bin isn?t on your path, and just running ./build/gems/bin/pry-remote will get an error unless you run it thru the bundler, as it won?t find the pry-remote gems. My hacked version of jirb script has a fallthru ?$*? at the end. I keep it in the parent directory of my archivesspace directory, so for me running: ../jirb.sh bundle exec pry-remote works. But my procedures for AS development environment are constantly being tweaked as I run into new issues. Lately, I?ve been trying to work RubyMine into the environment, but I can?t seem to be able to get it to find my Gems in the correct place. Before finding method of ?bundle exec? with those environment settings, I was keeping a duplicate set of Gems installed in the rbenv environment. I may have to go back to doing that to get RubyMine to find them. ? Steve. On Feb 10, 2016, at 9:34 AM, Esha Datta <esha at nyu.edu<mailto:esha at nyu.edu>> wrote: Thanks for your email. I got the gem to install as you had mentioned; however, I'm not sure how to get pry-remote to work. I see the message: [java] [pry-remote] Waiting for client on druby://127.0.0.1:9876<http://127.0.0.1:9876/> But, when I try to do pry-remote in the terminal, I get a bash error: command not found. I googled around trying to see how to run pry-remote within jruby and didn't find anything of value. These are the commands I tried: 1. pry-remote: Got an error: -bash: pry-remote: command not found 2. ./scripts/jruby -S pry-remote. Error: jruby: No such file or directory -- pry (LoadError) Thanks for your help! Esha On Feb 9, 2016 11:28 PM, "Mayo, Dave" <dave_mayo at harvard.edu<mailto:dave_mayo at harvard.edu>> wrote: Hi Esha, As far as running bundler, I've found that running: ./build/run bundler -Dgemfile=../backend/Gemfile from the archivesspace root directory gets the contents of that Gemfile installed properly. I'm running my devserver via `.build/run backend:devserver`. If you're doing the same, `binding.pry` STILL won't work, because the backend doesn't log directly to console, and whatever intermediate it's using (Ant? I think Ant) only does output. What I DID get working was installing the pry-remote Gem, and then doing `binding.remote_pry` and connecting from another terminal. Let me know if this works out for you, or if there's anything else I can possibly do to help. - Dave Mayo Library Software Engineer Harvard University -> HUIT -> LTS From: Esha Datta <esha at nyu.edu<mailto:esha at nyu.edu>> Reply-To: "esha at nyu.edu<mailto:esha at nyu.edu>" <esha at nyu.edu<mailto:esha at nyu.edu>>, Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Date: Tuesday, February 9, 2016 at 8:04 PM To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] archivesspace newbie questions Hi, I'm a developer with NYU's Bobst Library and am new to JRuby and ArchivesSpace. I have to write a plugin and am trying to use pry for stepping through some code. I have done some rails work before and tried to install pry by adding it to the backend/ Gemfile and then running ./scripts/jruby -S bundle install. The command ran but didn't install pry. I then tried to install it by doing the following: ./scripts/jruby -S gem install pry That installed pry but when I tried to use it in the backend by doing "binding.pry", I got an error saying it's an undefined method. If anyone has pointers as to how to use pry in this environment, I'd really appreciate it. Basically, I'm trying to figure out what certain objects have and return in order to write the plugin. Also, I will need to write tests for the plugin. Sorry, if I've missed documentation in how to write tests for the plugin and how to run them. If someone could point me to that, I'd really appreciate it. Thanks for your time. Esha _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/f6238f67/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: jirb.sh Type: application/octet-stream Size: 1286 bytes Desc: jirb.sh URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/f6238f67/attachment.obj> From prom at illinois.edu Wed Feb 10 12:25:30 2016 From: prom at illinois.edu (Prom, Christopher John) Date: Wed, 10 Feb 2016 17:25:30 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <BN1PR03MB266B6F9243AA9675FB5D1C6E5D70@BN1PR03MB266.namprd03.prod.outlook.com> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> <BN1PR03MB266B6F9243AA9675FB5D1C6E5D70@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <B5202FAF-827F-4A90-AECD-3B5EBB59FCA6@illinois.edu> Phil, What you re suggesting makes good sense. We can clean up the documentation to address the security points. I suspect part of what happened here is the ?aspace? user issue was introduced inadvertently with the new code development, so simply recommending it be deleted would be the main way forward. Unless it was created in some other way, but I am not sure how, since in the case of my DB, I was looking at a version that had ONLY be touched by the migrator. Chris On Feb 10, 2016, at 8:44 AM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Chris, all: I think that the Archon-to-ArchivesSpace migration documentation could be improved. I think it needs to be made explicit that all users will be migrated from Archon to ArchivesSpace. As you and I are both on the Migration Sub-Committee, I think we could look at improving the documentation for migration (unless of course the user migration is altered). Also, I am not sure that user migration is a negative as long as users/passwords are managed. When I have migrated from Archon to ArchivesSpace, I have deleted any users that would not be needed by staff and made sure passwords were altered. With all this being said, I do agree that a discussion about security should be had. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Wednesday, February 10, 2016 8:32 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] More admins, more problems Thanks Mark, this is good to hear. I do think that a security review would be helpful. My concern here is not so much with the tool, as with the fact that the app allows there to be blank passwords, which makes me wonder if there are other security problems lurking somewhere. I know this issue had come up several years ago, and I thought fixed at that time, but apparently crept back in. I also second the idea of an accessibility review. On the web team we have here, we have one person dedicated to accessibility issues, and it contributes immensely to the project as a whole to have a focus on this. Chris On Feb 9, 2016, at 9:07 PM, Custer, Mark <mark.custer at YALE.EDU<mailto:mark.custer at YALE.EDU>> wrote: Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] on behalf of Prom, Christopher John [prom at illinois.edu<mailto:prom at illinois.edu>] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=BQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=jGJMaTc-8I-z6_tkoj_Qyi4UF1KtYBfcz4s2Ly33jmw&m=JBM5eVzEZn8p99s9zqOEyqrU9PSic9qevEstgnoRq2s&s=Wn9kgsQlk3ScpDWo9h9qop9800isIJZ3prq0kEeKjmo&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=BQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=jGJMaTc-8I-z6_tkoj_Qyi4UF1KtYBfcz4s2Ly33jmw&m=JBM5eVzEZn8p99s9zqOEyqrU9PSic9qevEstgnoRq2s&s=Wn9kgsQlk3ScpDWo9h9qop9800isIJZ3prq0kEeKjmo&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/a8a48126/attachment.html> From christine.dibella at lyrasis.org Wed Feb 10 13:15:01 2016 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Wed, 10 Feb 2016 18:15:01 +0000 Subject: [Archivesspace_Users_Group] more ArchivesSpace screencasts up and your chance to participate Message-ID: <SN1PR08MB1967DB5331CB9D00413FF393F1D70@SN1PR08MB1967.namprd08.prod.outlook.com> The video library for the ArchivesSpace User Screencast Series is growing! As always, you can access the newest additions by logging in to the authentication site at http://docs.archivesspace.org. Thanks to Christy Tomecek, Angela Kroeger, and Kate Tasker for sharing their expertise with the community in this round. There are still plenty of topics available, so if you're willing to demonstrate your ArchivesSpace knowledge - whether you're new to ArchivesSpace or a total pro - and earn a little extra cash at the same time, take a look at the instructions for participating on the ArchivesSpace wiki at https://archivesspace.atlassian.net/wiki/display/ADC/Instructions+for+Creating+a+Video+for+the+ArchivesSpace+User+Screencast+Series. Please get in touch if you'd like to record a screencast, or if you'd like to suggest additional topics. Christine Christine Di Bella Community Outreach and Support Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:image003.png at 01CE734E.FD759D30] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/1e3555f5/attachment.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/20160210/1e3555f5/attachment.png> From Patricia.Burdick at colby.edu Wed Feb 10 13:30:11 2016 From: Patricia.Burdick at colby.edu (Patricia Burdick) Date: Wed, 10 Feb 2016 13:30:11 -0500 Subject: [Archivesspace_Users_Group] Cannot delete duplicate agent record Message-ID: <CA+zRjC362POcvXirEUx-AC5teq39=WMmMBPsVQhqm_7kDC4wxw@mail.gmail.com> Hello-- I have tried both Delete methods to remove a duplicate agent record. An error message results: Record deletion failed: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`archivesspace`.`linked_agent_term`, CONSTRAINT `linked_agent_term_ibfk_1` FOREIGN KEY (`linked_agents_rlshp_id`) REFERENCES `linked_agents_rlshp` (`id`)) Has anyone found a reason and solution for this situation? Many thanks, Pat Burdick Assistant Director for Special Collections -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/8902fae4/attachment.html> From Chris.Fitzpatrick at lyrasis.org Wed Feb 10 15:59:25 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Wed, 10 Feb 2016 20:59:25 +0000 Subject: [Archivesspace_Users_Group] More admins, more problems In-Reply-To: <B5202FAF-827F-4A90-AECD-3B5EBB59FCA6@illinois.edu> References: <DCB910FAD4CF9343B3E424AF5F3310252FD19874@x10-mbx4.yu.yale.edu> <C2FFF851-40BF-4E45-9CFF-ACCEEB91CB85@illinois.edu> <DCB910FAD4CF9343B3E424AF5F3310252FD19AFF@x10-mbx4.yu.yale.edu> <78026FE1-07BC-449B-96DA-C20201D098EC@illinois.edu> <BN1PR03MB266B6F9243AA9675FB5D1C6E5D70@BN1PR03MB266.namprd03.prod.outlook.com>, <B5202FAF-827F-4A90-AECD-3B5EBB59FCA6@illinois.edu> Message-ID: <BY2PR08MB0636A2B97B9E5C36615F479FBD70@BY2PR08MB063.namprd08.prod.outlook.com> Hi All, Just to clarify a couple of things.... The staff UI forces you to make a password when you create a new user. However, if you create a user via that api ( when logged in as an administrator ), you do not have to give a password. There are a use case for having users with blank passwords ( for example, if you want to have a script or service that interacts with the API ). Of course, you should actively monitor your users permissions. The migrators create users and assign permission as there were in AT/Archon. After running a migration, you should examine your users to make sure they migrated correctly, and reset their passwords. Also, just to be clear, these aren't database users, but just ASpace users. That said, sure, it's probably pretty easy feature if we wanted to have the ability to enforce some kind of password strength policy. Could be done as a plugin, even... Password reset is also doable, but it slightly tricky...most reset features require access to a mail server, which ASpace currently doesn't have. Again, not rocket science, but would be an additional thing thrown into the mix ( and, also another security attack vector ). Or maybe we could think of an alternative reset that doesn't use a mail server? But yeah, again let me know if you have any questions... best, Chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Prom, Christopher John <prom at illinois.edu> Sent: Wednesday, February 10, 2016 6:25 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Phil, What you re suggesting makes good sense. We can clean up the documentation to address the security points. I suspect part of what happened here is the ?aspace? user issue was introduced inadvertently with the new code development, so simply recommending it be deleted would be the main way forward. Unless it was created in some other way, but I am not sure how, since in the case of my DB, I was looking at a version that had ONLY be touched by the migrator. Chris On Feb 10, 2016, at 8:44 AM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Chris, all: I think that the Archon-to-ArchivesSpace migration documentation could be improved. I think it needs to be made explicit that all users will be migrated from Archon to ArchivesSpace. As you and I are both on the Migration Sub-Committee, I think we could look at improving the documentation for migration (unless of course the user migration is altered). Also, I am not sure that user migration is a negative as long as users/passwords are managed. When I have migrated from Archon to ArchivesSpace, I have deleted any users that would not be needed by staff and made sure passwords were altered. With all this being said, I do agree that a discussion about security should be had. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John Sent: Wednesday, February 10, 2016 8:32 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] More admins, more problems Thanks Mark, this is good to hear. I do think that a security review would be helpful. My concern here is not so much with the tool, as with the fact that the app allows there to be blank passwords, which makes me wonder if there are other security problems lurking somewhere. I know this issue had come up several years ago, and I thought fixed at that time, but apparently crept back in. I also second the idea of an accessibility review. On the web team we have here, we have one person dedicated to accessibility issues, and it contributes immensely to the project as a whole to have a focus on this. Chris On Feb 9, 2016, at 9:07 PM, Custer, Mark <mark.custer at YALE.EDU<mailto:mark.custer at YALE.EDU>> wrote: Chris, all: Speaking as someone who isn't a security expert at all, I'd just point out that the two migration tools are not part of the ArchivesSpace core code -- also, I've felt really good with how security is handled in the core code so far, although I do scratch my head at times with how global, repository, and user permissions and preferences function. Still, I have no clue why the migration tools would need to create an additional "system admin" user during the migration process, but since they both do, I'd expect that the migration tools should at least remove those users after the migration, as you suggested, Chris. Since that's not the case, I just wanted to bring the issue up to a wider audience again. Speaking of which, I'll make sure to post the same message to the Google Group tomorrow (but if anyone wants to beat me to it, feel free!). All that said, I'm sure that code reviews, security audits, and the like would be extremely welcome -- ArchivesSpace is open-source software, after all! I'd also like to make a pitch that an accessibility review be conducted for the staff interface, if a major one hasn't already been conducted, as I've heard from some staff members that they have a difficult time with the default styling (particularly with contrast and other visual elements), but I'm loath to admit that we haven't done that yet. Perhaps other have? Lastly, I'd actually say that my confidence with the software has only grown the more that I've used it and seen the amount of work that's gone into it in such a short amount of time already. And I expect that the quality will only increase as more and more developers start pitching in with bug fixes and the like... but right now, the migration specialist position hasn't been refilled, and I don't believe there are any plans to do that (although I'd recommend it, since my usual response is that the optimal number of staff is usually more than what you've got if you're growing, even though that's not a solution in and of itself, of course!). Mark ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] on behalf of Prom, Christopher John [prom at illinois.edu<mailto:prom at illinois.edu>] Sent: Tuesday, February 09, 2016 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] More admins, more problems Mark, Thanks for bringing this up. I just checked and in the case of the archon migrations, the asadmin user is not created. However, it does make a user ?aspace? and grants it full admin rights. Even worse, you can login as that user with NO password (i.e. field is blank). So, that one should definitely be killed off manually or even better the migration tool should delete it when done. In addition, there is another problem with archon migrations, in that the migration tool takes ALL of the existing users from archon DBs, and migrates them into aspace as read only users with the same login, and no password. You can then login to the app with the old users name and no password (field is blank) and can view but not edit data. All of the users the migration tool create are read only?but still this is a security problem since someone might be able to view restricted data or find a hack to get more permissions on the DB. As a related question, how is security handled generally in ASpace? Is it relying on an external security library, or bespoke code, or some combination of the two? The discovery of these types of things, in all honesty, does not engender confidence, and probably indicates the need for a thorough security audit. While the above problems can be cleaned up after the fact, not an ideal solution. Chris Prom Univeristy of Illinois Archives On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>> wrote: All, I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user?s perspective). As most are aware, when you install ArchivesSpace without any configuration changes, you wind up with a single admin account in ArchivesSpace that has a username equal to ?admin? and a password set to be the same. You?ll want to change this password to something else long before you go into production mode. For the most part, I think that people take care of this on or around day one, but if you can log into your ASpace application using that username and password, you?ll want to update that password to something else that?s a lot more secure! Less well known is what happens when you use the migration tool to populate your ArchivesSpace database (I sent an email about this to the listserv way back on May 8, 2015, but I don?t know if what I?m about to describe is documented anywhere else yet). If you?ve migrated to ArchivesSpace using the Archivists? Toolkit migration tool (and I?m pretty sure this happens with the Archon tool, as well), then another admin user will be added to your database. This admin user will have a username that?s equal to ?asadmin?. I?m not actually sure why the migration tool creates another user (or if the current versions still do this), especially since you have to supply admin credentials to the migration tool to run against the ASpace API, but I know that this happened during our migration process ? and I?ve seen this phantom admin user account in other ArchivesSpace installations, as well. When we discovered this new user, we deleted it from our database immediately after our final migration process. So, I?d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an ?asadmin? account, whether you?re in production or not (the password is easy to guess, since it?s the same as the default admin user?s password). If you can log in that way, I?d suggest deleting that user immediately! Mark _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=BQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=jGJMaTc-8I-z6_tkoj_Qyi4UF1KtYBfcz4s2Ly33jmw&m=JBM5eVzEZn8p99s9zqOEyqrU9PSic9qevEstgnoRq2s&s=Wn9kgsQlk3ScpDWo9h9qop9800isIJZ3prq0kEeKjmo&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=BQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=jGJMaTc-8I-z6_tkoj_Qyi4UF1KtYBfcz4s2Ly33jmw&m=JBM5eVzEZn8p99s9zqOEyqrU9PSic9qevEstgnoRq2s&s=Wn9kgsQlk3ScpDWo9h9qop9800isIJZ3prq0kEeKjmo&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/1e6592dd/attachment.html> From esha at nyu.edu Wed Feb 10 16:19:32 2016 From: esha at nyu.edu (Esha Datta) Date: Wed, 10 Feb 2016 16:19:32 -0500 Subject: [Archivesspace_Users_Group] archivesspace newbie questions In-Reply-To: <AB853B8A-D14D-498C-BC4B-9C74168788E5@eservices.virginia.edu> References: <CAFkiWRU-e5XeehK-4L+khpNR8_7UqGgB5Fdqbg4B6TOshbeHbA@mail.gmail.com> <D2E02009.F816%dave_mayo@harvard.edu> <CAFkiWRVJN6r+m7SnWaWP5iMNd-A+pTp3P2hU3BKG1FPOPsNuwQ@mail.gmail.com> <AB853B8A-D14D-498C-BC4B-9C74168788E5@eservices.virginia.edu> Message-ID: <CAFkiWRV1Fc_ddtd4hyQSOjgQbi7BAUa=FSs4wEH50UnfKBegsQ@mail.gmail.com> Thanks Steve. Dave also emailed me and said that I could just download pry-remote as a gem and use it with MRI Ruby which is what I did. On Wed, Feb 10, 2016 at 12:01 PM, Majewski, Steven Dennis (sdm7g) < sdm7g at eservices.virginia.edu> wrote: > > The gem and binaries should be installed in the archivesspace build/gems > directory, but ./build/gems/bin isn?t > on your path, and just running ./build/gems/bin/pry-remote will get an > error unless you run it thru the bundler, > as it won?t find the pry-remote gems. > > > My hacked version of jirb script has a fallthru ?$*? at the end. > I keep it in the parent directory of my archivesspace directory, so for me > running: > > ../jirb.sh bundle exec pry-remote > > works. > > > But my procedures for AS development environment are constantly being > tweaked as I run into new issues. > Lately, I?ve been trying to work RubyMine into the environment, but I > can?t seem to be able to get it > to find my Gems in the correct place. Before finding method of ?bundle > exec? with those environment settings, > I was keeping a duplicate set of Gems installed in the rbenv environment. > I may have to go back to doing > that to get RubyMine to find them. > > > ? Steve. > > > On Feb 10, 2016, at 9:34 AM, Esha Datta <esha at nyu.edu> wrote: > > Thanks for your email. I got the gem to install as you had mentioned; > however, I'm not sure how to get pry-remote to work. I see the message: > > [java] [pry-remote] Waiting for client on druby://127.0.0.1:9876 > > But, when I try to do pry-remote in the terminal, I get a bash error: > command not found. I googled around trying to see how to run pry-remote > within jruby and didn't find anything of value. These are the commands I > tried: > > 1. pry-remote: Got an error: -bash: pry-remote: command not found > > 2. ./scripts/jruby -S pry-remote. Error: jruby: No such file or directory > -- pry (LoadError) > > Thanks for your help! > > > Esha > > > On Feb 9, 2016 11:28 PM, "Mayo, Dave" <dave_mayo at harvard.edu> wrote: > > Hi Esha, > > As far as running bundler, I've found that running: > > ./build/run bundler -Dgemfile=../backend/Gemfile > > from the archivesspace root directory gets the contents of that Gemfile > installed properly. > > I'm running my devserver via `.build/run backend:devserver`. If you're > doing the same, `binding.pry` STILL won't work, because the backend doesn't > log directly to console, and whatever intermediate it's using (Ant? I think > Ant) only does output. What I DID get working was installing the > pry-remote Gem, and then doing `binding.remote_pry` and connecting from > another terminal. > > Let me know if this works out for you, or if there's anything else I can > possibly do to help. > > - Dave Mayo > Library Software Engineer > Harvard University -> HUIT -> LTS > > > From: Esha Datta <esha at nyu.edu> > Reply-To: "esha at nyu.edu" <esha at nyu.edu>, Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > Date: Tuesday, February 9, 2016 at 8:04 PM > To: "archivesspace_users_group at lyralists.lyrasis.org" < > archivesspace_users_group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] archivesspace newbie questions > > > Hi, > > I'm a developer with NYU's Bobst Library and am new to JRuby and > ArchivesSpace. I have to write a plugin and am trying to use pry for > stepping through some code. I have done some rails work before and tried to > install pry by adding it to the backend/ Gemfile > and then running ./scripts/jruby -S bundle install. The command ran but > didn't install pry. I then tried to install it by doing the following: > ./scripts/jruby -S gem install pry > That installed pry but when I tried to use it in the backend by doing > "binding.pry", I got an error saying it's an undefined method. If anyone > has pointers as to how to use pry in this environment, I'd really > appreciate it. Basically, I'm trying to figure > out what certain objects have and return in order to write the plugin. > > Also, I will need to write tests for the plugin. Sorry, if I've missed > documentation in how to write tests for the plugin and how to run them. If > someone could point me to that, I'd really appreciate it. > > Thanks for your time. > > Esha > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/28d39379/attachment.html> From Chris.Fitzpatrick at lyrasis.org Wed Feb 10 17:30:11 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Wed, 10 Feb 2016 22:30:11 +0000 Subject: [Archivesspace_Users_Group] Fwd: seeking clarification on transfer of digital objects between repositories In-Reply-To: <CAP4gJsU4ZP0CDw__8keNi5ScsafM5i-j14Kog8zwsa4MP6WZQw@mail.gmail.com> References: <CAP4gJsWozk8Z8xR6nLxiG7zgsR2GLzHXndvKpRme+OBwbaU_hQ@mail.gmail.com>, <CAP4gJsU4ZP0CDw__8keNi5ScsafM5i-j14Kog8zwsa4MP6WZQw@mail.gmail.com> Message-ID: <BY2PR08MB0639094BAEF98B6D1AC7B94FBD70@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Yeah....sorry, just got to look at this... There is a bit of conceptual thing here...a DO can be tied to multiple resources/AOs. It is also scoped to a repo. When you transfer the resource, does the DO follow? What if it's tied to another resource in the source repo? Does that make sense? I might be missing something obvious... b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Jason Loeffler <j at minorscience.com> Sent: Wednesday, February 10, 2016 12:03 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Fwd: seeking clarification on transfer of digital objects between repositories Pursuant to AR-1405<https://archivesspace.atlassian.net/browse/AR-1405>, can anyone replicate the issue or otherwise assist in this matter? In summary, during a resource-to-repository transfer, attached digital object instances are not transferred to new repository. Thanks, Jason ---------- Forwarded message ---------- From: Jason Loeffler <j at minorscience.com<mailto:j at minorscience.com>> Date: Thu, Feb 4, 2016 at 7:23 PM Subject: seeking clarification on transfer of digital objects between repositories To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Having a little trouble understanding what's going on with transferring digital objects between repos. A repository to repository transfer of archival objects works fine. All linked digital objects are successfully transferred. However, when a resource is transferred, linked digital objects are not transferred. For testing purposes, I've created a simple hierarchy of archival objects and linked a digital object to a child item. Using both the GUI and API, I've initiated a transfer of the top-level resource to a target repository. It appears that the associated digital objects are not included in the transfer to the target repository and are orphaned at the originating repository. I am unable to use the API to transfer the orphaned digital objects to the new repository because the association between the archival object and digital object no longer exists. This is described more completely in the attached gist<https://gist.github.com/minorscience/930fd457f0815b63defd>. I posted something related here<https://archivesspace.atlassian.net/browse/AR-1405>. (Not sure if that's the right place.) Can someone confirm whether there is some design principle I am missing? Many thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/ea19515e/attachment.html> From brianjhoffman at gmail.com Wed Feb 10 19:30:26 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Wed, 10 Feb 2016 19:30:26 -0500 Subject: [Archivesspace_Users_Group] Cannot delete duplicate agent record In-Reply-To: <CA+zRjC362POcvXirEUx-AC5teq39=WMmMBPsVQhqm_7kDC4wxw@mail.gmail.com> References: <CA+zRjC362POcvXirEUx-AC5teq39=WMmMBPsVQhqm_7kDC4wxw@mail.gmail.com> Message-ID: <4FF4B8C6-426B-4F19-A9C3-C366BC377979@gmail.com> It looks like the agent you are trying to delete may be ?in a relationship?. If you can remove that relationship (and perhaps recreate it on the duplicate agent you wish to keep), that may solve the problem. If it doesn?t, there may be a bug. > On Feb 10, 2016, at 1:30 PM, Patricia Burdick <Patricia.Burdick at colby.edu> wrote: > > Hello-- > > I have tried both Delete methods to remove a duplicate agent record. An error message results: > > Record deletion failed: Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`archivesspace`.`linked_agent_term`, CONSTRAINT `linked_agent_term_ibfk_1` FOREIGN KEY (`linked_agents_rlshp_id`) REFERENCES `linked_agents_rlshp` (`id`)) > > Has anyone found a reason and solution for this situation? > > Many thanks, > Pat Burdick > Assistant Director for Special Collections > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From j at minorscience.com Wed Feb 10 23:11:29 2016 From: j at minorscience.com (Jason Loeffler) Date: Wed, 10 Feb 2016 23:11:29 -0500 Subject: [Archivesspace_Users_Group] Fwd: seeking clarification on transfer of digital objects between repositories In-Reply-To: <BY2PR08MB0639094BAEF98B6D1AC7B94FBD70@BY2PR08MB063.namprd08.prod.outlook.com> References: <CAP4gJsWozk8Z8xR6nLxiG7zgsR2GLzHXndvKpRme+OBwbaU_hQ@mail.gmail.com> <CAP4gJsU4ZP0CDw__8keNi5ScsafM5i-j14Kog8zwsa4MP6WZQw@mail.gmail.com> <BY2PR08MB0639094BAEF98B6D1AC7B94FBD70@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <CAP4gJsUgnwSsp256PrFEpYH4UzqBvdL3xF_k1+SYqFXVK=zVgg@mail.gmail.com> Hi Chris, Thanks for picking this up. Transferring a single resource and a.o. to a new repository does not include any attached d.o. instances. They do not follow and their :id parameters remain scoped to the origin repository. (This includes via the UI or via API calls.) I've transferred the d.o. manually (via the API) and they're properly scoped now but have no means to reattach to containing a.o. On the other hand, transferring an entire repository to the custody of another repository transfers all d.o. and preserves the relationship with the a.o. I can't think of a use case in which you would want to transfer select resources and a.o. from one repo to a new one while abandoning their d.o. in the origin repo. But it's entirely possible I'm missing something. JL On Wed, Feb 10, 2016 at 5:30 PM, Chris Fitzpatrick < Chris.Fitzpatrick at lyrasis.org> wrote: > Hi, > > > Yeah....sorry, just got to look at this... > > > There is a bit of conceptual thing here...a DO can be tied to multiple > resources/AOs. It is also scoped to a repo. When you transfer the resource, > does the DO follow? What if it's tied to another resource in the source > repo? > > > Does that make sense? I might be missing something obvious... > > > b,chris. > > > Chris Fitzpatrick | Developer, ArchivesSpace > Skype: chrisfitzpat | Phone: 918.236.6048 > http://archivesspace.org/ > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Jason Loeffler <j at minorscience.com> > *Sent:* Wednesday, February 10, 2016 12:03 AM > *To:* Archivesspace Users Group > *Subject:* [Archivesspace_Users_Group] Fwd: seeking clarification on > transfer of digital objects between repositories > > Pursuant to AR-1405 <https://archivesspace.atlassian.net/browse/AR-1405>, > can anyone replicate the issue or otherwise assist in this matter? > > In summary, during a resource-to-repository transfer, attached digital > object instances are not transferred to new repository. > > Thanks, Jason > > ---------- Forwarded message ---------- > From: Jason Loeffler <j at minorscience.com> > Date: Thu, Feb 4, 2016 at 7:23 PM > Subject: seeking clarification on transfer of digital objects between > repositories > To: Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > > > Having a little trouble understanding what's going on with transferring > digital objects between repos. > > A repository to repository transfer of archival objects works fine. All > linked digital objects are successfully transferred. However, when a > resource is transferred, linked digital objects are not transferred. > > For testing purposes, I've created a simple hierarchy of archival objects > and linked a digital object to a child item. Using both the GUI and API, > I've initiated a transfer of the top-level resource to a target repository. > It appears that the associated digital objects are not included in the > transfer to the target repository and are orphaned at the originating > repository. > > I am unable to use the API to transfer the orphaned digital objects to the > new repository because the association between the archival object and > digital object no longer exists. > > This is described more completely in the attached gist > <https://gist.github.com/minorscience/930fd457f0815b63defd>. I posted > something related here > <https://archivesspace.atlassian.net/browse/AR-1405>. (Not sure if that's > the right place.) > > Can someone confirm whether there is some design principle I am missing? > > Many thanks, Jason > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160210/1fac3e47/attachment.html> From jacqueline.rider at ptsem.edu Thu Feb 11 08:26:04 2016 From: jacqueline.rider at ptsem.edu (Rider, Jacqueline) Date: Thu, 11 Feb 2016 13:26:04 +0000 Subject: [Archivesspace_Users_Group] more ArchivesSpace screencasts up and your chance to participate In-Reply-To: <SN1PR08MB1967DB5331CB9D00413FF393F1D70@SN1PR08MB1967.namprd08.prod.outlook.com> References: <SN1PR08MB1967DB5331CB9D00413FF393F1D70@SN1PR08MB1967.namprd08.prod.outlook.com> Message-ID: <D2E1F551.92C2%jacqueline.rider@ptsem.edu> These are great. Thank you. I?d like to see a video on plugins: what plugins are available, what they each do, and how to install them. Maybe that?s more than one video. Thanks, Jackie Jacqueline Rider Digital Archivist Princeton Theological Seminary Library PO Box 821 Princeton NJ 08542 609-497-7862 jacqueline.rider at ptsem.edu Website: ptsem.edu/library<http://www.ptsem.edu/library/> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Date: Wednesday, February 10, 2016 at 1:15 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] more ArchivesSpace screencasts up and your chance to participate The video library for the ArchivesSpace User Screencast Series is growing! As always, you can access the newest additions by logging in to the authentication site at http://docs.archivesspace.org. Thanks to Christy Tomecek, Angela Kroeger, and Kate Tasker for sharing their expertise with the community in this round. There are still plenty of topics available, so if you?re willing to demonstrate your ArchivesSpace knowledge ? whether you?re new to ArchivesSpace or a total pro ? and earn a little extra cash at the same time, take a look at the instructions for participating on the ArchivesSpace wiki at https://archivesspace.atlassian.net/wiki/display/ADC/Instructions+for+Creating+a+Video+for+the+ArchivesSpace+User+Screencast+Series. Please get in touch if you?d like to record a screencast, or if you?d like to suggest additional topics. Christine Christine Di Bella Community Outreach and Support Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:image003.png at 01CE734E.FD759D30] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/47d51f7c/attachment.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/20160211/47d51f7c/attachment.png> From akroeger at unomaha.edu Thu Feb 11 10:55:07 2016 From: akroeger at unomaha.edu (Angela Kroeger) Date: Thu, 11 Feb 2016 15:55:07 +0000 Subject: [Archivesspace_Users_Group] Digital objects In-Reply-To: <CAP4gJsW00iim8H1pCszWNQeiQPAOCbUSJaoUE7BzyWDpxfq=Yg@mail.gmail.com> References: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> <EF74AAC3-7C6B-4BFD-8981-23A1F8E8BEFE@yale.edu> <CAP4gJsW00iim8H1pCszWNQeiQPAOCbUSJaoUE7BzyWDpxfq=Yg@mail.gmail.com> Message-ID: <DM2PR07MB97397FA3D3F6DD5AF61F043D3A80@DM2PR07MB973.namprd07.prod.outlook.com> Thank you to both Maureen Callahan and Jason Loeffler for thoughtful replies. Maureen?s point about adherence to DACS principles is well-made, and I?ll discuss it with my director in an upcoming meeting. Jason, you mentioned AR-1314 in relation to the bug I experienced, and that is it exactly. A comment on AR-1314 by Chris Fitzpatrick said that the digital object could not be created if the DO had a note in it (which mine did). I tried again, leaving the note out of the DO, and it saved just fine. So it?s the presence of a note field that prevents the DO from saving. At least I know it?s a known issue, though it looks like you and Max Eckard are unable to reproduce it on your systems. We?re on version 1.4.2, and I?m using Windows 8.1 and Chrome browser if that helps. Chris?s comment about the ?Create DO Modal . . . loading note types that aren?t valid for DO?s? rings true. When I was creating the DO through the instances section of the resource record, the DO?s note drop list included Scope and Contents. When I created the DO independently, Scope and Contents was not an option, but Summary was. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/bbfe2d46/attachment.html> From zenright at une.edu Thu Feb 11 14:12:53 2016 From: zenright at une.edu (Zachary Enright) Date: Thu, 11 Feb 2016 19:12:53 +0000 Subject: [Archivesspace_Users_Group] Uploaded resources do not appear Message-ID: <BLUPR0701MB19536234DC46C2599D974F3CCFA80@BLUPR0701MB1953.namprd07.prod.outlook.com> Hi all, We are currently running v1.2.6-dev08. We recently ran out of space where the directory lived. Our IT were able to get us more space. Although disk space was an issue for data/file-system content that would want to be written to the archivesspace directory, the database lived on another logical volume that did not run out of space. Since then we are able to upload new resources however they do not appear on the resources page when we go looking for them. Perhaps some things are not properly in sync? Zachary Enright NEOHC Archivist/UNE Special Collections Processing Archivist University of New England 11 Hills Beach Road Biddeford, ME 04005 207-602-2131 zenright at une.edu<mailto:zenright at une.edu> This e-mail may contain information that is privileged and confidential. If you suspect that you were not the intended recipient, please delete it and notify the sender as soon as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/2b19bfe1/attachment.html> From helen.thomas at nicholls.edu Thu Feb 11 14:41:50 2016 From: helen.thomas at nicholls.edu (Helen Thomas) Date: Thu, 11 Feb 2016 13:41:50 -0600 Subject: [Archivesspace_Users_Group] Components not loading in Public UI Message-ID: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> Hello all, I'm experiencing a problem where none of the components for my resource records are loading in the public interface. Instead, I get a perpetual loading GIF that never goes away. I noticed this after I attempted to add components to a couple of records. At first I thought that just those records had crashed (one now shows a completely blank screen for the staff side of the record in either edit or view mode), but after checking I found that none of my resource components are loading. We have recently upgraded to a production server, but the tech at campus IT believes this component issue to be software related. Does anyone have an idea what may be going on or how to address this problem? Best, Helen -- *Helen Thomas* Assistant Archivist Ellender Library, Nicholls State University helen.thomas at nicholls.edu | (985) 448-4644 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/18a4af6c/attachment.html> From j at minorscience.com Thu Feb 11 14:58:54 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 11 Feb 2016 14:58:54 -0500 Subject: [Archivesspace_Users_Group] Uploaded resources do not appear In-Reply-To: <BLUPR0701MB19536234DC46C2599D974F3CCFA80@BLUPR0701MB1953.namprd07.prod.outlook.com> References: <BLUPR0701MB19536234DC46C2599D974F3CCFA80@BLUPR0701MB1953.namprd07.prod.outlook.com> Message-ID: <CAP4gJsVdHWmG3yRpS_dJLNBJOkdbk2phBHq2JrxkiaKgAdJ1Ow@mail.gmail.com> Sounds like an indexing problem. That can be rebuilt easily. Can you confirm whether you are unable to view any resources or just newly added resources? As an aside, have you considered upgrading your ArchivesSpace instance to the latest stable release? Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Thu, Feb 11, 2016 at 2:12 PM, Zachary Enright <zenright at une.edu> wrote: > Hi all, > > We are currently running v1.2.6-dev08. We recently ran out of space where > the directory lived. Our IT were able to get us more space. Although disk > space was an issue for data/file-system content that would want to be > written to the archivesspace directory, the database lived on another > logical volume that did not run out of space. Since then we are able to > upload new resources however they do not appear on the resources page when > we go looking for them. Perhaps some things are not properly in sync? > > > > Zachary Enright > > NEOHC Archivist/UNE Special Collections Processing Archivist > > University of New England > > 11 Hills Beach Road > > Biddeford, ME 04005 > > 207-602-2131 > > zenright at une.edu > > > This e-mail may contain information that is privileged and confidential. > If you suspect that you were not the intended recipient, please delete it > and notify the sender as soon as possible. > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/9f8d58ab/attachment.html> From j at minorscience.com Thu Feb 11 15:01:17 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 11 Feb 2016 15:01:17 -0500 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> Message-ID: <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> Helen, Can you tell me your ArchivesSpace version number? Are you unable to view records from both the staff interface and the public interface? Does it affect all records or just newly created records? Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> wrote: > Hello all, > > I'm experiencing a problem where none of the components for my resource > records are loading in the public interface. Instead, I get a perpetual > loading GIF that never goes away. I noticed this after I attempted to add > components to a couple of records. At first I thought that just those > records had crashed (one now shows a completely blank screen for the staff > side of the record in either edit or view mode), but after checking I found > that none of my resource components are loading. We have recently upgraded > to a production server, but the tech at campus IT believes this component > issue to be software related. > > Does anyone have an idea what may be going on or how to address this > problem? > > Best, > Helen > > -- > *Helen Thomas* > Assistant Archivist > Ellender Library, Nicholls State University > helen.thomas at nicholls.edu | (985) 448-4644 > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/d60d097e/attachment.html> From j at minorscience.com Thu Feb 11 15:06:12 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 11 Feb 2016 15:06:12 -0500 Subject: [Archivesspace_Users_Group] Digital objects In-Reply-To: <DM2PR07MB97397FA3D3F6DD5AF61F043D3A80@DM2PR07MB973.namprd07.prod.outlook.com> References: <DM2PR07MB97354A71C07E6495A13F83BD3D60@DM2PR07MB973.namprd07.prod.outlook.com> <EF74AAC3-7C6B-4BFD-8981-23A1F8E8BEFE@yale.edu> <CAP4gJsW00iim8H1pCszWNQeiQPAOCbUSJaoUE7BzyWDpxfq=Yg@mail.gmail.com> <DM2PR07MB97397FA3D3F6DD5AF61F043D3A80@DM2PR07MB973.namprd07.prod.outlook.com> Message-ID: <CAP4gJsWCEO=JwyvdE+yS=MQSQri8ym-LyTQ6xaHtxE6SioaREg@mail.gmail.com> Hi Angela, Looks like a bug. I was able to reproduce. Thanks for further defining the issue. I've updated AR-1314 documenting the issue. Best, Jason Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Thu, Feb 11, 2016 at 10:55 AM, Angela Kroeger <akroeger at unomaha.edu> wrote: > Thank you to both Maureen Callahan and Jason Loeffler for thoughtful > replies. Maureen?s point about adherence to DACS principles is well-made, > and I?ll discuss it with my director in an upcoming meeting. > > > > Jason, you mentioned AR-1314 in relation to the bug I experienced, and > that is it exactly. A comment on AR-1314 by Chris Fitzpatrick said that the > digital object could not be created if the DO had a note in it (which mine > did). I tried again, leaving the note out of the DO, and it saved just > fine. So it?s the presence of a note field that prevents the DO from > saving. At least I know it?s a known issue, though it looks like you and > Max Eckard are unable to reproduce it on your systems. We?re on version > 1.4.2, and I?m using Windows 8.1 and Chrome browser if that helps. > > > > Chris?s comment about the ?Create DO Modal . . . loading note types that > aren?t valid for DO?s? rings true. When I was creating the DO through the > instances section of the resource record, the DO?s note drop list included > Scope and Contents. When I created the DO independently, Scope and > Contents was not an option, but Summary was. > > > > Angela Kroeger > > akroeger at unomaha.edu > > Archives and Special Collections Associate > > Dr. C.C. and Mabel L. Criss Library > > University of Nebraska at Omaha > > (402) 554-4159 > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/8bf09984/attachment.html> From jNovakovic at museumofplay.org Thu Feb 11 15:08:59 2016 From: jNovakovic at museumofplay.org (Novakovic, Julia) Date: Thu, 11 Feb 2016 15:08:59 -0500 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> Message-ID: <6568E68D6B5225458D97A8685E972C570AEB7EACF1@Exch2K7.strongmuseum.org> Hi Jason, The Strong has also been having this same issue [Components not appearing] with the Public Interface, just with our newly-created records. [All the data which migrated from Archivists? Toolkit came over fine and appears correctly in the Public Interface.] Looks like we are running Version v1.1.2. I?ve attached a previous email chain that I sent to the listserv. Thanks! --Julia Julia Novakovic Archivist Associate Editor, American Journal of Play The Strong One Manhattan Square Rochester, NY 14607 U.S.A. Tel 585-410-6307 Fax 585-423-1886 jnovakovic at museumofplay.org<mailto:jnovakovic at museumofplay.org> www.museumofplay.org<http://www.museumofplay.org/> The Strong is home to: International Center for the History of Electronic Games | National Toy Hall of Fame | World Video Game Hall of Fame Brian Sutton-Smith Library and Archives of Play | Woodbury School | American Journal of Play From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jason Loeffler Sent: Thursday, February 11, 2016 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Components not loading in Public UI Helen, Can you tell me your ArchivesSpace version number? Are you unable to view records from both the staff interface and the public interface? Does it affect all records or just newly created records? Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu<mailto:helen.thomas at nicholls.edu>> wrote: Hello all, I'm experiencing a problem where none of the components for my resource records are loading in the public interface. Instead, I get a perpetual loading GIF that never goes away. I noticed this after I attempted to add components to a couple of records. At first I thought that just those records had crashed (one now shows a completely blank screen for the staff side of the record in either edit or view mode), but after checking I found that none of my resource components are loading. We have recently upgraded to a production server, but the tech at campus IT believes this component issue to be software related. Does anyone have an idea what may be going on or how to address this problem? Best, Helen -- Helen Thomas Assistant Archivist Ellender Library, Nicholls State University helen.thomas at nicholls.edu<mailto:helen.thomas at nicholls.edu> | (985) 448-4644<tel:%28985%29%20448-4644> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/04c93fd0/attachment.html> -------------- next part -------------- An embedded message was scrubbed... From: "Novakovic, Julia" <jNovakovic at museumofplay.org> Subject: Re: [Archivesspace_Users_Group] component trees not appearing in public view of AS Date: Tue, 1 Dec 2015 16:25:12 -0500 Size: 215948 URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/04c93fd0/attachment.mht> From helen.thomas at nicholls.edu Thu Feb 11 15:22:48 2016 From: helen.thomas at nicholls.edu (Helen Thomas) Date: Thu, 11 Feb 2016 14:22:48 -0600 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> Message-ID: <CAPJRQSUeRtacpp09sDSBzH=V3U5zbyFKg8E6_vtUnWmaAwfXQQ@mail.gmail.com> Jason, Thanks for the quick reply. I am running version 1.4.2. All of my records are affected on the public interface. I have only tried to edit two resource records since this started happening. For the first one (which I edited extensively using RDE), I can't see anything from the staff interface. In fact, when I click View or Edit, my browser goes to this URL ( http://archives.nicholls.edu/staff/resources/21/edit) where I can only see a blank white screen. Based on the other records that I can see on the staff interface, I think that this URL should be http://archives.nicholls.edu/staff/resources/21/edit#tree::resource_21, and I am being somehow redirected. When I use that URL, I am taken to this: The other records are displaying perfectly on the staff side, even the one that I just did a small edit to today (added only a series title). None of these are entirely new collections - I'm currently trying to edit records that I imported as MARC catalog records. Helen ? On Thu, Feb 11, 2016 at 2:01 PM, Jason Loeffler <j at minorscience.com> wrote: > Helen, > > Can you tell me your ArchivesSpace version number? > > Are you unable to view records from both the staff interface and the > public interface? Does it affect all records or just newly created records? > > Jason Loeffler > Technology Consultant > The American Academy in Rome > Minor Science | Application Development & Metadata Strategy > Brooklyn, New York > > > On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> > wrote: > >> Hello all, >> >> I'm experiencing a problem where none of the components for my resource >> records are loading in the public interface. Instead, I get a perpetual >> loading GIF that never goes away. I noticed this after I attempted to add >> components to a couple of records. At first I thought that just those >> records had crashed (one now shows a completely blank screen for the staff >> side of the record in either edit or view mode), but after checking I found >> that none of my resource components are loading. We have recently upgraded >> to a production server, but the tech at campus IT believes this component >> issue to be software related. >> >> Does anyone have an idea what may be going on or how to address this >> problem? >> >> Best, >> Helen >> >> -- >> *Helen Thomas* >> Assistant Archivist >> Ellender Library, Nicholls State University >> helen.thomas at nicholls.edu | (985) 448-4644 >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- *Helen Thomas* Assistant Archivist Ellender Library, Nicholls State University helen.thomas at nicholls.edu | (985) 448-4644 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3c105401/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: LoadingLegendre.JPG Type: image/jpeg Size: 25421 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3c105401/attachment.jpe> From j at minorscience.com Thu Feb 11 15:58:23 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 11 Feb 2016 15:58:23 -0500 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAPJRQSUeRtacpp09sDSBzH=V3U5zbyFKg8E6_vtUnWmaAwfXQQ@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> <CAPJRQSUeRtacpp09sDSBzH=V3U5zbyFKg8E6_vtUnWmaAwfXQQ@mail.gmail.com> Message-ID: <CAP4gJsWtiUCN3zyVMFzKfLcw1Qn8wg00k7tJ_LuHwqXm-eAPZw@mail.gmail.com> You're correct, the path on the staff side should include #tree::resource_21. What's the URL for your public interface? JL On Thu, Feb 11, 2016 at 3:22 PM, Helen Thomas <helen.thomas at nicholls.edu> wrote: > Jason, > > Thanks for the quick reply. I am running version 1.4.2. All of my records > are affected on the public interface. > > I have only tried to edit two resource records since this started > happening. For the first one (which I edited extensively using RDE), I > can't see anything from the staff interface. In fact, when I click View or > Edit, my browser goes to this URL ( > http://archives.nicholls.edu/staff/resources/21/edit) where I can only > see a blank white screen. Based on the other records that I can see on the > staff interface, I think that this URL should be > http://archives.nicholls.edu/staff/resources/21/edit#tree::resource_21, > and I am being somehow redirected. When I use that URL, I am taken to this: > > > The other records are displaying perfectly on the staff side, even the one > that I just did a small edit to today (added only a series title). None of > these are entirely new collections - I'm currently trying to edit records > that I imported as MARC catalog records. > > Helen > ? > > On Thu, Feb 11, 2016 at 2:01 PM, Jason Loeffler <j at minorscience.com> > wrote: > >> Helen, >> >> Can you tell me your ArchivesSpace version number? >> >> Are you unable to view records from both the staff interface and the >> public interface? Does it affect all records or just newly created records? >> >> Jason Loeffler >> Technology Consultant >> The American Academy in Rome >> Minor Science | Application Development & Metadata Strategy >> Brooklyn, New York >> >> >> On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> >> wrote: >> >>> Hello all, >>> >>> I'm experiencing a problem where none of the components for my resource >>> records are loading in the public interface. Instead, I get a perpetual >>> loading GIF that never goes away. I noticed this after I attempted to add >>> components to a couple of records. At first I thought that just those >>> records had crashed (one now shows a completely blank screen for the staff >>> side of the record in either edit or view mode), but after checking I found >>> that none of my resource components are loading. We have recently upgraded >>> to a production server, but the tech at campus IT believes this component >>> issue to be software related. >>> >>> Does anyone have an idea what may be going on or how to address this >>> problem? >>> >>> Best, >>> Helen >>> >>> -- >>> *Helen Thomas* >>> Assistant Archivist >>> Ellender Library, Nicholls State University >>> helen.thomas at nicholls.edu | (985) 448-4644 >>> >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> Archivesspace_Users_Group at lyralists.lyrasis.org >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> >>> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> > > > -- > *Helen Thomas* > Assistant Archivist > Ellender Library, Nicholls State University > helen.thomas at nicholls.edu | (985) 448-4644 > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/d6119312/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: LoadingLegendre.JPG Type: image/jpeg Size: 25421 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/d6119312/attachment.jpe> From j at minorscience.com Thu Feb 11 16:03:20 2016 From: j at minorscience.com (Jason Loeffler) Date: Thu, 11 Feb 2016 16:03:20 -0500 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <6568E68D6B5225458D97A8685E972C570AEB7EACF1@Exch2K7.strongmuseum.org> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> <6568E68D6B5225458D97A8685E972C570AEB7EACF1@Exch2K7.strongmuseum.org> Message-ID: <CAP4gJsVkQwJ5=xTG8UCrqgQZMEDm-TCqqSwbao+iiVOXA1+u6A@mail.gmail.com> I'm not sure whether rebuilding the index <http://archivesspace.github.io/archivesspace/user/re-creating-indexes/> would help but it's worth a shot. Is that something your team can try? On Thu, Feb 11, 2016 at 3:08 PM, Novakovic, Julia < jNovakovic at museumofplay.org> wrote: > Hi Jason, > > > > The Strong has also been having this same issue [Components not > appearing] with the Public Interface, just with our newly-created records. > [All the data which migrated from Archivists? Toolkit came over fine and > appears correctly in the Public Interface.] Looks like we are running Version > v1.1.2. I?ve attached a previous email chain that I sent to the listserv. > > > > Thanks! > > --Julia > > > > > > > > Julia Novakovic > > Archivist > > Associate Editor, *American Journal of Play* > > *The Strong* > > One Manhattan Square > > Rochester, NY 14607 U.S.A. > > Tel 585-410-6307 > > Fax 585-423-1886 > > jnovakovic at museumofplay.org > > www.museumofplay.org > > > > The Strong is home to: > > International Center for the History of Electronic Games | National Toy > Hall of Fame | World Video Game Hall of Fame > Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American > Journal of Play* > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Jason > Loeffler > *Sent:* Thursday, February 11, 2016 3:01 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Components not loading in > Public UI > > > > Helen, > > > > Can you tell me your ArchivesSpace version number? > > > > Are you unable to view records from both the staff interface and the > public interface? Does it affect all records or just newly created records? > > > > Jason Loeffler > > Technology Consultant > > The American Academy in Rome > > Minor Science | Application Development & Metadata Strategy > > Brooklyn, New York > > > > > > On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> > wrote: > > Hello all, > > > > I'm experiencing a problem where none of the components for my resource > records are loading in the public interface. Instead, I get a perpetual > loading GIF that never goes away. I noticed this after I attempted to add > components to a couple of records. At first I thought that just those > records had crashed (one now shows a completely blank screen for the staff > side of the record in either edit or view mode), but after checking I found > that none of my resource components are loading. We have recently upgraded > to a production server, but the tech at campus IT believes this component > issue to be software related. > > > > Does anyone have an idea what may be going on or how to address this > problem? > > > > Best, > > Helen > > > > -- > > *Helen Thomas* > > Assistant Archivist > > Ellender Library, Nicholls State University > > helen.thomas at nicholls.edu | (985) 448-4644 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > > ---------- Forwarded message ---------- > From: "Novakovic, Julia" <jNovakovic at museumofplay.org> > To: Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > Cc: "Rugaber, Ross" <RRugaber at museumofplay.org> > Date: Tue, 1 Dec 2015 16:25:12 -0500 > Subject: Re: [Archivesspace_Users_Group] component trees not appearing in > public view of AS > > Hi all, > > > > I wrote several weeks ago to the ArchivesSpace listserv to see if there > was an easy fix for our issue of the hand-entered resource component tree > and related record components not appearing on the public side of AS. I > have made sure that all the correct fields are marked to ?Publish? and I > also tried clicking ?Publish All? from the internal side of the main > resource record, but to no avail. > > > > From the public side, I right-clicked on the page and selected ?Inspect > element? to see if it would tell me what the error actually is. Screenshot > of the errors attached. > > > > Our Director of IT noted that it was coming up as a server side error, but > he has tried over the last few weeks to determine what that error might be, > if it?s on our end. He searched the AS forum but couldn?t find any answers > there either. Does anyone have any other advice? > > > > Thank you in advance! > > --Julia > > > > > > Julia Novakovic > > Archivist > > Associate Editor, *American Journal of Play* > > *The Strong* > > One Manhattan Square > > Rochester, NY 14607 U.S.A. > > Tel 585-410-6307 > > Fax 585-423-1886 > > jnovakovic at museumofplay.org > > www.museumofplay.org > > > > The Strong is home to: > > International Center for the History of Electronic Games | National Toy > Hall of Fame | World Video Game Hall of Fame > Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American > Journal of Play* > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Brad > Westbrook > *Sent:* Monday, November 02, 2015 5:02 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] component trees not appearing > in public view of AS > > > > Hi, Julia, > > > > Is it possible that the components are not marked to be published? > > > > > > > > If not, you can A) indicate each component in the tree you want to > publish to the public interface or B) select the ?Publish All? option on > the parent record, which will publish everything in the description. > > > > > > > > Let us know if that does work. > > > > Cheers, > > > > Brad W. > > > > Bradley D. Westbrook > > Program Manager > > brad.westbrook at lyrasis.org <brad at archivesspace.org> > > 800.999.8558 x2910 > > 678.235.2910 > > bradley_d_westbrook (Skype) > > [image: cid:image003.png at 01CE734E.FD759D30] > > > > > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Novakovic, > Julia > *Sent:* Monday, November 02, 2015 1:20 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* [Archivesspace_Users_Group] component trees not appearing in > public view of AS > > > > Hello, > > > > My institution had about 50 full resource records in Archivists? Toolkit > which mapped/migrated perfectly over to ArchivesSpace earlier this year. > However, I?m having an issue with the resources I?ve hand-entered into AS > since then; the component trees appear fine in the internal side, but in > the public view, there is just a three-bar churning icon there. Does > anyone have any advice on what needs to happen so that *all* of our > resources? components appear in the public view? [Screenshots comparing the > two (public-side view) attached.] There is nothing else missing from the > internal side to the public side for the newly hand-entered records, and I > have tried clicking ?Publish All? to no avail. > > > > Related: Keyword searching in the internal side works perfectly for > discovery of these hand-entered records. When I go to the public view, > though, I will get the same search results, but when I click on any of > those file records, I get the error message ?We?re sorry, but something > went wrong.? Does this mean something isn?t linking correctly? I?d > appreciate any advice that I can pass along to our Director of IT to fix > the problem. > > > > Thanks! > > --Julia > > > > > > Julia Novakovic > > Archivist > > Associate Editor, *American Journal of Play* > > *The Strong* > > One Manhattan Square > > Rochester, NY 14607 U.S.A. > > Tel 585-410-6307 > > Fax 585-423-1886 > > jnovakovic at museumofplay.org > > www.museumofplay.org > > > > The Strong is home to: > > International Center for the History of Electronic Games | National Toy > Hall of Fame | World Video Game Hall of Fame > Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American > Journal of Play* > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/f8ca8f34/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1137 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/f8ca8f34/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 13275 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/f8ca8f34/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 11388 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/f8ca8f34/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 7640 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/f8ca8f34/attachment-0001.png> From helen.thomas at nicholls.edu Thu Feb 11 17:14:03 2016 From: helen.thomas at nicholls.edu (Helen Thomas) Date: Thu, 11 Feb 2016 16:14:03 -0600 Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAP4gJsVkQwJ5=xTG8UCrqgQZMEDm-TCqqSwbao+iiVOXA1+u6A@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> <6568E68D6B5225458D97A8685E972C570AEB7EACF1@Exch2K7.strongmuseum.org> <CAP4gJsVkQwJ5=xTG8UCrqgQZMEDm-TCqqSwbao+iiVOXA1+u6A@mail.gmail.com> Message-ID: <CAPJRQSW2ZiWeu8b_SHZA8Z-M8WNzujMxBedKFUKeyTOZq4UDdA@mail.gmail.com> Hi Jason, The URL for our public interface is archives.nicholls.edu. Currently it is accessible only on our campus. I followed the directions to re-index and nothing changed. I'm also getting this 404 Error when I do inspect element on any of the public interface collection pages: GET http://archives.nicholls.edu/staff/tree?uri=%2Frepositories%2F2%2Fresources%2F21 404 (Not Found) Helen On Thu, Feb 11, 2016 at 3:03 PM, Jason Loeffler <j at minorscience.com> wrote: > I'm not sure whether rebuilding the index > <http://archivesspace.github.io/archivesspace/user/re-creating-indexes/> would > help but it's worth a shot. Is that something your team can try? > > On Thu, Feb 11, 2016 at 3:08 PM, Novakovic, Julia < > jNovakovic at museumofplay.org> wrote: > >> Hi Jason, >> >> >> >> The Strong has also been having this same issue [Components not >> appearing] with the Public Interface, just with our newly-created records. >> [All the data which migrated from Archivists? Toolkit came over fine and >> appears correctly in the Public Interface.] Looks like we are running Version >> v1.1.2. I?ve attached a previous email chain that I sent to the listserv. >> >> >> >> Thanks! >> >> --Julia >> >> >> >> >> >> >> >> Julia Novakovic >> >> Archivist >> >> Associate Editor, *American Journal of Play* >> >> *The Strong* >> >> One Manhattan Square >> >> Rochester, NY 14607 U.S.A. >> >> Tel 585-410-6307 >> >> Fax 585-423-1886 >> >> jnovakovic at museumofplay.org >> >> www.museumofplay.org >> >> >> >> The Strong is home to: >> >> International Center for the History of Electronic Games | National Toy >> Hall of Fame | World Video Game Hall of Fame >> Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American >> Journal of Play* >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Jason >> Loeffler >> *Sent:* Thursday, February 11, 2016 3:01 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Components not loading in >> Public UI >> >> >> >> Helen, >> >> >> >> Can you tell me your ArchivesSpace version number? >> >> >> >> Are you unable to view records from both the staff interface and the >> public interface? Does it affect all records or just newly created records? >> >> >> >> Jason Loeffler >> >> Technology Consultant >> >> The American Academy in Rome >> >> Minor Science | Application Development & Metadata Strategy >> >> Brooklyn, New York >> >> >> >> >> >> On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> >> wrote: >> >> Hello all, >> >> >> >> I'm experiencing a problem where none of the components for my resource >> records are loading in the public interface. Instead, I get a perpetual >> loading GIF that never goes away. I noticed this after I attempted to add >> components to a couple of records. At first I thought that just those >> records had crashed (one now shows a completely blank screen for the staff >> side of the record in either edit or view mode), but after checking I found >> that none of my resource components are loading. We have recently upgraded >> to a production server, but the tech at campus IT believes this component >> issue to be software related. >> >> >> >> Does anyone have an idea what may be going on or how to address this >> problem? >> >> >> >> Best, >> >> Helen >> >> >> >> -- >> >> *Helen Thomas* >> >> Assistant Archivist >> >> Ellender Library, Nicholls State University >> >> helen.thomas at nicholls.edu | (985) 448-4644 >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Novakovic, Julia" <jNovakovic at museumofplay.org> >> To: Archivesspace Users Group < >> archivesspace_users_group at lyralists.lyrasis.org> >> Cc: "Rugaber, Ross" <RRugaber at museumofplay.org> >> Date: Tue, 1 Dec 2015 16:25:12 -0500 >> Subject: Re: [Archivesspace_Users_Group] component trees not appearing in >> public view of AS >> >> Hi all, >> >> >> >> I wrote several weeks ago to the ArchivesSpace listserv to see if there >> was an easy fix for our issue of the hand-entered resource component tree >> and related record components not appearing on the public side of AS. I >> have made sure that all the correct fields are marked to ?Publish? and I >> also tried clicking ?Publish All? from the internal side of the main >> resource record, but to no avail. >> >> >> >> From the public side, I right-clicked on the page and selected ?Inspect >> element? to see if it would tell me what the error actually is. Screenshot >> of the errors attached. >> >> >> >> Our Director of IT noted that it was coming up as a server side error, >> but he has tried over the last few weeks to determine what that error might >> be, if it?s on our end. He searched the AS forum but couldn?t find any >> answers there either. Does anyone have any other advice? >> >> >> >> Thank you in advance! >> >> --Julia >> >> >> >> >> >> Julia Novakovic >> >> Archivist >> >> Associate Editor, *American Journal of Play* >> >> *The Strong* >> >> One Manhattan Square >> >> Rochester, NY 14607 U.S.A. >> >> Tel 585-410-6307 >> >> Fax 585-423-1886 >> >> jnovakovic at museumofplay.org >> >> www.museumofplay.org >> >> >> >> The Strong is home to: >> >> International Center for the History of Electronic Games | National Toy >> Hall of Fame | World Video Game Hall of Fame >> Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American >> Journal of Play* >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Brad >> Westbrook >> *Sent:* Monday, November 02, 2015 5:02 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] component trees not appearing >> in public view of AS >> >> >> >> Hi, Julia, >> >> >> >> Is it possible that the components are not marked to be published? >> >> >> >> >> >> >> >> If not, you can A) indicate each component in the tree you want to >> publish to the public interface or B) select the ?Publish All? option on >> the parent record, which will publish everything in the description. >> >> >> >> >> >> >> >> Let us know if that does work. >> >> >> >> Cheers, >> >> >> >> Brad W. >> >> >> >> Bradley D. Westbrook >> >> Program Manager >> >> brad.westbrook at lyrasis.org <brad at archivesspace.org> >> >> 800.999.8558 x2910 >> >> 678.235.2910 >> >> bradley_d_westbrook (Skype) >> >> [image: cid:image003.png at 01CE734E.FD759D30] >> >> >> >> >> >> >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of >> *Novakovic, Julia >> *Sent:* Monday, November 02, 2015 1:20 PM >> *To:* archivesspace_users_group at lyralists.lyrasis.org >> *Subject:* [Archivesspace_Users_Group] component trees not appearing in >> public view of AS >> >> >> >> Hello, >> >> >> >> My institution had about 50 full resource records in Archivists? Toolkit >> which mapped/migrated perfectly over to ArchivesSpace earlier this year. >> However, I?m having an issue with the resources I?ve hand-entered into AS >> since then; the component trees appear fine in the internal side, but in >> the public view, there is just a three-bar churning icon there. Does >> anyone have any advice on what needs to happen so that *all* of our >> resources? components appear in the public view? [Screenshots comparing the >> two (public-side view) attached.] There is nothing else missing from the >> internal side to the public side for the newly hand-entered records, and I >> have tried clicking ?Publish All? to no avail. >> >> >> >> Related: Keyword searching in the internal side works perfectly for >> discovery of these hand-entered records. When I go to the public view, >> though, I will get the same search results, but when I click on any of >> those file records, I get the error message ?We?re sorry, but something >> went wrong.? Does this mean something isn?t linking correctly? I?d >> appreciate any advice that I can pass along to our Director of IT to fix >> the problem. >> >> >> >> Thanks! >> >> --Julia >> >> >> >> >> >> Julia Novakovic >> >> Archivist >> >> Associate Editor, *American Journal of Play* >> >> *The Strong* >> >> One Manhattan Square >> >> Rochester, NY 14607 U.S.A. >> >> Tel 585-410-6307 >> >> Fax 585-423-1886 >> >> jnovakovic at museumofplay.org >> >> www.museumofplay.org >> >> >> >> The Strong is home to: >> >> International Center for the History of Electronic Games | National Toy >> Hall of Fame | World Video Game Hall of Fame >> Brian Sutton-Smith Library and Archives of Play | Woodbury School | *American >> Journal of Play* >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- *Helen Thomas* Assistant Archivist Ellender Library, Nicholls State University helen.thomas at nicholls.edu | (985) 448-4644 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/5e51e7cd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 7640 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/5e51e7cd/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1137 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/5e51e7cd/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 13275 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/5e51e7cd/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 11388 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/5e51e7cd/attachment-0001.jpg> From dundon at ucsc.edu Thu Feb 11 20:13:21 2016 From: dundon at ucsc.edu (Kate Dundon) Date: Thu, 11 Feb 2016 17:13:21 -0800 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> Message-ID: <CA+OhMU8LDO8jTig4vmQGcxHAP_oMUkPF7+GducqzCC0=uhbbaQ@mail.gmail.com> UCSC Special Collections & Archives also supports AS-76. We are experiencing a scenario similar to Harvard's. Kate Dundon Archivist, Special Collections & Archives University Library University of California, Santa Cruz 831-502-7587 On Tue, Feb 9, 2016 at 3:41 PM, Cyndi Shein <cyndi.shein at unlv.edu> wrote: > UNLV University Libraries supports AS-76 as well. > > Cyndi Shein > Head, Special Collections Technical Services > University Libraries, University of Nevada, Las Vegas > cyndi.shein at unlv.edu (702) 895-2223 > > unlvspecialcollections <https://www.facebook.com/unlvspecialcollections> > > > On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu> > wrote: > >> UC San Diego concurs. The experience (and resulting complications with >> managing data effectively) that Anne describes below are identical to UC >> San Diego?s, and we too support AS-76. >> >> >> >> *Laurel McPhee Dougherty* >> >> Supervisory Archivist, Special Collections & Archives Program >> >> UC San Diego Library | ( 858-534-5619 | * l1dougherty at ucsd.edu >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Engelhart, >> Anne >> *Sent:* Tuesday, February 09, 2016 8:58 AM >> *To:* Archivesspace Users Group < >> archivesspace_users_group at lyralists.lyrasis.org> >> *Cc:* Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu> >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to >> post Harvard University?s position on AS-76. I also posted it on JIRA, >> AS-76. (Here it is below.) >> >> >> >> Anne Engelhart >> >> Head, Collection Services >> >> Schlesinger Library, Radcliffe Institute >> >> 10 Garden St. >> >> Cambridge, MA 02138 >> >> 617.495.8521 >> >> >> >> *Restoration of processing status to collection management records in >> ArchivesSpace* >> >> *Summary * >> >> Sometime during the past year, ArchivesSpace made a major change to its >> functionality. >> >> ? It eliminated the processing status from collection management >> records. >> >> ? The processing status and associated date were converted to >> ?event? records. >> >> This has created several problems for archivists at Harvard who rely on >> this information for workflow and reporting purposes including: >> >> ? The ?processing status? in all accessions migrated from the >> Archivists? Toolkit (AT) for which processing statuses were assigned now >> displays as ?Not specified? (see Screenshot 1). >> >> ? The conversion of processing status from a condition (or type) >> to an event overcomplicates what was previously a fairly straightforward >> piece of collection management information. >> >> *Detailed discussion of issues* >> >> There are three troubling issues associated with this change in >> functionality. >> >> 1. The first should be important to all archives: by converting >> the processing status to an event, the ArchivesSpace developers have >> changed the nature of the data. A status is not equivalent to an event, >> although they can be related. There is one and only one ?status? at any >> one time, but there can be multiple events. Events can lead to status >> changes. For example, two ?partially processed? events may or may not >> lead to a status of ?processed,? because it is entirely possible that three >> or more processing events might be needed to conclude that the status of >> the collection is ?processed.? In addition, some statuses may have no >> relation to an event. For example ?Unknown? is a possible processing >> status. Finally, how does an archivist identify ?unprocessed? accessions >> in this scenario? This is another ?non-event?. Are ArchivesSpace users >> expected to run a report on all accessions and look for those for which >> there is no ?processing? event? Since there are many possible event types, >> this seems counter-productive and unnecessarily complex. >> >> >> >> 2. The second issue is perhaps unique to Harvard albeit no less >> critical. The Harvard AT-to-AS migration did not create event records based >> on processing status. Instead, while our back-end data has processing >> status in it, these statuses are, troublingly, not visible to staff. >> Instead the processing status displays as ?not specified? (Screenshot >> 1). The same record in AT displays a processing status. (Screenshot 2) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Screenshot 1* >> >> *Screenshot 2* >> >> >> >> 3. Processing status is a critical piece of information that >> should be available to archivists for reporting on their accessions. In >> Harvard's current ArchivesSpace environment is that it is not possible to >> understand the scope and nature of our backlogs. The staff member who >> discovered this issue previously used the AT to readily determine the >> number of unprocessed accessions. While attempting to gather the same >> information from ArchivesSpace, the staff member found that it was not >> possible to achieve the same results with existing ArchivesSpace >> functionality. >> >> >> >> It is essential to the Harvard University ArchivesSpace user community >> that processing status be restored to its original functionality. The >> restoration of processing status to collection management records would: >> >> ? Allow archivists to report out on backlog and processing >> statistics; >> >> ? Assist archivists in resource allocation planning for grant >> proposals and yearly projects; and >> >> ? Make this data currently in the back-end of ArchivesSpace >> easily available to archivists >> >> As such, Harvard University ArchivesSpace user community supports the >> JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. >> >> >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of >> *MATTHEW R FRANCIS >> *Sent:* Monday, January 04, 2016 12:56 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> Quick FYI update for anyone interested in this thread. After a couple of >> off-list discussions I decided to go ahead an create a new "feature >> request" ticket in JIRA requesting that the "Processing Status" field be >> restored to the Collection Management sub-record. The ticket can be viewed >> at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for >> forgetting to submit in the form of a user story!). >> >> >> >> If there are any questions, concerns, or clarifications that I can help >> with related to the request please let me know. >> >> >> >> -Matt >> >> >> >> *Matt** Francis* >> >> Archivist for Collection Management >> >> Special Collections Library >> Penn State University >> >> >> ------------------------------ >> >> *From: *"MATTHEW R FRANCIS" <mrf22 at psu.edu> >> *To: *"Archivesspace Users Group" < >> archivesspace_users_group at lyralists.lyrasis.org> >> *Sent: *Wednesday, November 25, 2015 4:50:24 PM >> *Subject: *Re: >> [Archivesspace_Users_Group] Collection management - processing status >> disappeared... >> >> >> >> Thank you Brad for your explanation for why the change occurred with the >> processing status field, and thank you Kate, Noah, and Carolyn for your >> additional thoughts and feedback. >> >> >> >> Based on all of the provided feedback I asked some of our staff to >> work/test the new functionality while trying to consider the intent behind >> the changes, our existing local workflows and collections metadata, and the >> abstract "what do we consider processing status to mean". Based on this >> examination of the new functionality we would like to provide the following >> feedback (many of which have already been stated in this email thread): >> >> - In regards to "an event record allows much more information to be >> associated with the event", it has been our local practice and belief that >> more nuanced processing information that would help researchers and staff >> better understand a finding aid/the physical collection should be recorded >> in a corresponding "Processing Information" note (which is informed by our >> interpretation of DACS 7.1.8). That said, we do appreciate that the event >> record allows for the capturing of some metadata that would be less >> relevant to researchers, and consequently a place where additional metadata >> could be recorded outside of the aforementioned note field. >> - After examining our "processing status" data and discussing the >> new functionality, we agree with Kate's observation that "events and >> processing statuses are not logical equivalents." Additionally, we also >> agree with Noah's comment "that a resource or accession will always have >> only one current status." >> - Additionally, based on our examination, we do not believe that is >> ideal or logical to separate "processing status" from collection management >> records that still include: "processing priority", "processing plan", and >> "processors". >> - Our local workflows appear to be at a high level similar to what >> Carolyn has reported, and along with the data we had already created to >> take advantage of the previous functionality, we also preferred the >> simplicity of the processing status being a simple drop-down selection in >> the collection management records. >> - Based on our local use the processing status field, along with the >> current status of the ASpace tool, we found it much easier to report on >> collection status and to locate appropriate collections projects for our >> workers with the previous functionality over the current. >> - Finally, we also echo Kate's sentiment in that we do not understand >> why the new event features requires the removal of the processing status >> from the collection management records and consequently wonder if there is >> any reason not to have both? >> >> Due to the above points we are of the opinion that if the new event >> features cannot be appropriately maintained while also having the >> processing status functionality reside in the collection management >> records, we would be in favor of a return to the previous functionality, or >> a new approach that is more similar to the previous functionality. With >> that said, we understand that our rationale for this request is largely >> based on our local understanding of the role of the processing status >> field, our local workflows, and and our existing data. Because of this we >> recognize that not all ASpace members might share our perspective, and >> consequently we welcome continued discussion on this subject as appropriate. >> >> >> >> Thank you again to everyone who have already participated in the >> conversation, and we hope that as a community we can reach a consensus on >> the best direction for us to proceed in the near future. >> >> >> >> Hope all of you have a wonderful Thanksgiving. >> >> >> >> -Matt >> >> >> >> *Matt** Francis* >> >> Archivist for Collection Management >> >> Special Collections Library >> Penn State University >> >> >> ------------------------------ >> >> *From: *"Runyon, Carolyn" <Carolyn-Runyon at utc.edu> >> *To: *"Archivesspace Users Group" < >> archivesspace_users_group at lyralists.lyrasis.org> >> *Sent: *Tuesday, November 24, 2015 2:12:09 PM >> *Subject: *Re: >> [Archivesspace_Users_Group] Collection management - processing status >> disappeared... >> >> >> >> We used the Processing Status field in the Collection Management module >> to track processing of our all our Resource records. It?s a little less >> complex than the data needed to populate an Event. I preferred the basic >> dropdown menu offered in Collection Management because it doesn?t require >> and Event Date/Time or a link it to an Agent. With legacy data, I won?t >> able to link an accurate Agent or Date to my processing events, which means >> I?ll have to devise some sort of input workaround for undated and anonymous >> Events. >> >> >> >> One last note, when Processing Status became and Event, Event Date/Time >> and Agent Links were populated, but they?re not accurate. They appear to >> reflect the Agent who selected the Processing Status and the Timestamp of >> when the Agent made the Processing Status selection. This means that if I >> want accurate data, I?ll need to clean up this legacy data. >> >> >> >> Cheers, >> >> Carolyn >> >> >> >> >> >> >> >> Carolyn Runyon >> Assistant Head of Collection Services and Director of Special Collections >> University of Tennessee at Chattanooga Library >> 615 McCallie Ave., Chattanooga, TN 37403 >> Carolyn-Runyon at utc.edu, (423) 425-4503 >> Dept. 6456, LIB 439D >> >> >> >> On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu> wrote: >> >> I tend to agree with Kate here. It seems useful to allow a resource or >> accession to have lots of processing events associated with it (who did >> what, when), but it also seems that a resource or accession will always >> have only one current status (processed, not processed, partially >> processed, etc.). >> >> >> >> Also, associated events do not display in ?edit? mode for resources or >> accessions (collection management sub-records do). As a result, it?s a bit >> complicated to figure out what the processing status is if you have to sort >> through a long list of associated events in ?view? mode. >> >> >> >> -Noah >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf >> Of *Bowers, Kate A. >> *Sent:* Thursday, November 19, 2015 9:40 AM >> *To:* Archivesspace Users Group < >> archivesspace_users_group at lyralists.lyrasis.org> >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> >> Brad, >> >> Thanks for your very thorough reply! >> >> I think you presented this as an either/or choice. However, because >> events and processing status are not logical equivalents (they may be >> associated in that the status may be the result of an event, but it does >> not have to be), I do not understand why adding features to the events >> record requires removal of the status. I short, is there any reason not to >> have both? >> >> Thanks again, >> >> Kate >> >> Kate Bowers >> Collections Services Archivist for Metadata, Systems, and Standards >> Harvard University Archives >> Cambridge, Massachusetts, USA >> voice: (617) 384-7787 >> fax: (617) 495-8011 >> kate_bowers at harvard.edu >> ------------------------------ >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < >> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of >> Brad Westbrook <brad.westbrook at lyrasis.org> >> *Sent:* Wednesday, November 18, 2015 6:04:27 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> Hi. >> >> >> >> Certainly it is possible and reasonable to have a discussion of how to >> adjust this change in functionality to make it more satisfying and less >> confusing, including reverting back to the functionality first included in >> ArchivesSpace. >> >> >> >> As I recall that functionality, it consisted of the ability to link a >> single collection management record to a material description record >> (accession, resource, or digital object but not components for resources >> and digital objects) and, further, to indicate in that collection >> management record the processing status of the material being described. >> Default terms were ?completed?, ?in_progress?, and ?new?, but the >> controlled value list was completely configurable. So institutions could >> add any terms they wanted to that list but they could only ever apply one >> status term to the material being described at a given time. >> >> >> >> We removed this field from the collection management field with the >> understanding such data would be better handled as event information and >> with the understanding that a change in status is first an event >> accomplished at a time and by an agent. We envisioned several benefits to >> this change: >> >> >> >> 1) As before, an organization has complete liberty to decide what >> terms it wants to use for expressing processing events and changes in >> processing status, as well as for any other events an institution chooses >> to track. The ?Event Event Type? list is completely configurable. >> >> >> >> 2) An event record allows much more information to be associated >> with the event, including a descriptive note about the event, when the >> event occurred, and who was responsible for the event. It struck us that >> knowing that processing of a collection was completed on a certain date and >> by a certain individual could be more useful information that know >> processing was simply completed. >> >> >> >> 3) Multiple event records can be associated to the same material >> description record. For instance, using event records it would be possible >> to indicate when processing of material started in one event record and >> when it was completed in another. >> >> >> >> 4) Multiple event records can be linked to component records. >> Thus for processing projects split into parallel parts, it would be >> possible to track, say, the processing progress of series. >> >> >> >> In short, our belief is that the collection management record in >> conjunction with event records provides a more comprehensive and flexible >> way for organizations to record collection management information. In that >> relationship, the collection management record is the location for >> planning?indicating processing priority, estimating processing time, >> indicating processing plan(s) and processor(s), but also noting funding >> source and whether rights are determined (it?s questionable whether or not >> these last two should be included in the collection management >> record)?while the event record is for recording completion (or not) of >> processing / administrative tasks associated with the materials?acquiring a >> purchase agreement, starting processing, completing processing, etc. >> >> >> >> There are requisites for this, of course: >> >> >> >> 1) Institutional policies regarding what events are to be tracked >> and what event vocabulary is to be used. >> >> >> >> 2) A process for creating and sharing reports that relate material >> descriptions, collection management, and events in meaningful ways. A >> segment of the ArchivesSpace community has been working to develop a >> reporting process, but the trajectory being taken will place the burden on >> institutions to define reports (You can, btw, see a record of this effort at >> https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> >> (current work) and >> https://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> >> (past work). It was also noted in the ArchivesSpace developers meeting >> last week, that information of this type would be very suitable for >> displaying in a dashboard widget. Of course, institutions can already >> build their own reporting and define their own reports by using report >> software to extract and format data from the ArchivesSpace MySQL database. >> >> >> >> But these would be requisites for any collection management information, >> supplemented or not by event information. They would be requisites for a >> reversion for a return to the previous data model. >> >> >> >> Let me close with two observations to other parts of this thread: >> >> >> >> 1) The display problem that Noah noted in his comment yesterday is >> a remnant of moving collection status to events. There is a bug report >> requesting its correction at AR-1324 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=> >> . >> >> >> >> 2) The presence of the ?Collection Management Processing Status? in >> the list of controlled values is also remnant of that change. It should be >> removed , unless there is a collective decision to revert. Thanks for >> pointing that out, Kelly. >> >> >> >> So it would be great to hear others weigh in on this. Collection >> management and event information have, as far as I know, no prevailing >> models or standards that we can simply follow. The closest to such is the >> de facto collection management sub-record created for accessions in the >> Archivists? Toolkit, which was generalized for all top-level material >> descriptions in ArchivesSpace and supplemented by the inclusion of events. >> The ArchivesSpace event module is itself an extension of the PREMIS events. >> >> >> >> Best, >> >> >> >> Brad W. >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf >> Of *MATTHEW R FRANCIS >> *Sent:* Wednesday, November 18, 2015 4:49 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> For the reasons outlined by Kate, and seconded by Glynn, we have also >> found this change rather confusing, and unfortunately it has hampered our >> ability to identify and report on various issues related to processing >> status, including the previously mentioned backlog issue. >> >> >> >> I do not know if this is an issue that others would like revisited, but >> from our perspective we would welcome a conversation on if there is better >> alternative moving forward (including possibly reverting back to the >> pre-v1.3 set-up). >> >> >> >> -Matt >> >> >> >> *Matt* *Francis* >> >> Archivist for Collection Management >> >> Special Collections Library >> Penn State University >> >> >> ------------------------------ >> >> *From: *"Glynn Edwards" <gedwards at stanford.edu> >> *To: *"Archivesspace Users Group" < >> archivesspace_users_group at lyralists.lyrasis.org> >> *Sent: *Wednesday, November 18, 2015 11:13:44 AM >> *Subject: *Re: [Archivesspace_Users_Group] >> Collection management - processing status >> disappeared... >> >> >> >> Hi Kate, >> >> We're on the same page...I too find this rather confusing. It is not >> straightforward enough for tracking status of collections across holdings >> easily. >> >> Cheers, >> >> Glynn >> >> >> >> Glynn Edwards >> Head, Technical Services >> Director, ePADD project >> Special Collections >> Stanford University Libraries >> Stanford, CA 94305-6064 >> (650) 521-2255 | gedwards at stanford.edu >> >> >> ------------------------------ >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < >> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of >> Bowers, Kate A. <kate_bowers at harvard.edu> >> *Sent:* Tuesday, November 17, 2015 1:08 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> I am very confused. Can you explain how this is would work? How is an >> archivist supposed to understand an accession?s status from one or more >> associated ?events? rather than from a straightforward status? I can also >> see how this would make reporting out backlogs really difficult. >> >> >> >> The reason I ask is that I can see how an event can lead to a status, but >> it is entirely possible that a status may have no associated event. >> Furthermore, the same type of event may lead to different statuses. >> >> >> >> In brief, status is not the same as ?event?. I can think of a couple of >> examples to illustrate this: >> >> ? ?Unknown? can be a status, but it has no associated event >> >> ? ?Partially processed? can be both a status an event. However, >> if one ?partially processes? an accession once, then the accession remains >> partially processed. If one ?partially processes? again, it could be that >> the processing has been completed and the accession?s status is now >> ?processed? or it could be that the accession is still only ?partially >> processed? and that additional processing events will be necessary to reach >> a ?processed? status. >> >> >> >> Thanks, >> >> >> >> Kate >> >> >> >> >> >> *Kate Bowers* >> >> Collections Services Archivist for Metadata, Systems, and Standards >> >> Harvard University Archives >> >> kate_bowers at harvard.edu <megan_sniffin-marinoff at harvard.edu> >> >> 617.496.2713 >> >> voice: (617) 384-7787 >> >> fax: (617) 495-8011 >> >> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives >> >> Twitter: @k8_bowers >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf >> Of *Noah Huffman >> *Sent:* Tuesday, November 17, 2015 3:01 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> Hi Kelly, >> >> >> >> During a previous release (v1.3), I think Processing Status was moved >> from the collection management subrecord to an Event record. Here is a >> JIRA issue describing this change: >> https://archivesspace.atlassian.net/browse/AR-827 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> >> >> >> >> Here are some specifics: >> >> Remove ?Processing Status? Collection Management sub-record >> >> If data is present, migrate to Event record with these settings and >> linked to same record collection management sub-record is linked to: >> >> >> >> Type = ?Processing [Value in Collection Management Record for Processing >> Status]? >> >> >> >> Date/Time Specifier = ?Time stamp for last modification of Collection >> Management record? >> >> >> >> Label= Agent relationship >> >> >> >> Type=Single >> >> >> >> Role=Implementer >> >> >> >> Agent=ID of agent last modifying the collection management sub-record >> >> >> >> >> >> So, if you previously had processing status in a collection management >> subrecord, you might try browsing your event records to see if you can >> locate that data. >> >> >> >> Hope this helps, >> >> >> >> -Noah >> >> >> >> ================ >> >> Noah Huffman >> >> Archivist for Metadata, Systems, and Digital Records >> >> David M. Rubenstein Rare Book & Manuscript Library >> >> Duke University | 919-660-5982 >> >> http://library.duke.edu/rubenstein/ >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> >> >> >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ >> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org >> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf >> Of *Kelly Spring >> *Sent:* Tuesday, November 17, 2015 2:40 PM >> *To:* archivesspace_users_group at lyralists.lyrasis.org >> *Subject:* [Archivesspace_Users_Group] Collection management - >> processing status disappeared... >> >> >> >> Hello! >> >> >> >> Our Processing Status field is visible when using the Manage Controlled >> Value Lists feature; but is not present when actually working within a >> collection management sub-record in an accession or resource. Any tips or >> advice out there? >> >> >> >> Thank you and have a great day! >> >> *Kelly >> >> >> >> >> >> >> >> >> >> Kelly Spring >> >> Archivist for Special Collections >> >> University of California, Irvine Libraries >> >> (949) 824-6573 >> >> http://special.lib.uci.edu >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> >> >> >> >> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> >> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> >> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11771 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49510 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38864 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment-0001.png> From jsteele at jhu.edu Fri Feb 12 09:04:23 2016 From: jsteele at jhu.edu (Jordon Steele) Date: Fri, 12 Feb 2016 14:04:23 +0000 Subject: [Archivesspace_Users_Group] UI and agent module feature requests Message-ID: <fa8af4b1ebfc475489b458b2451aadd4@ESGMTWEX6.win.ad.jhu.edu> Hi all, I wanted to direct your attention to my creation and support of the following feature requests. If they are of interest to you, too, I encourage you to vote for them. UI-related (mainly staff-side) * "Expand all" and "collapse all" option in tree view: https://archivesspace.atlassian.net/browse/AS-82 * Choose order of main fields in the Resources module: https://archivesspace.atlassian.net/browse/AS-81 * Configure the search results screen: https://archivesspace.atlassian.net/browse/AR-996 * Option of displaying the tree view for a resource record on the left (a la AT): https://archivesspace.atlassian.net/browse/AS-79 Agents * Option to "show all resources/accessions" underneath a parent agent: https://archivesspace.atlassian.net/browse/AS-68 * Option to "show all linked agents" in an agent record: https://archivesspace.atlassian.net/browse/AS-80 Best, Jordon Jordon Steele Hodson Curator of the University Archives The Sheridan Libraries Johns Hopkins University 3400 N Charles Street Baltimore, MD 21218 410-516-5493 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/25c737bc/attachment.html> From Gregory.Farr at AustenRiggs.net Fri Feb 12 10:02:03 2016 From: Gregory.Farr at AustenRiggs.net (Gregory.Farr at AustenRiggs.net) Date: Fri, 12 Feb 2016 10:02:03 -0500 Subject: [Archivesspace_Users_Group] AUTO: Gregory Farr is out of the office (returning 02/16/2016) Message-ID: <OF59A33CBC.BA367ABA-ON85257F57.00529623-85257F57.00529623@AUSTENRIGGS.NET> I am out of the office until 02/16/2016. Note: This is an automated response to your message "[Archivesspace_Users_Group] UI and agent module feature requests" sent on 2/12/2016 9:04:23 AM. This is the only notification you will receive while this person is away. From Chris.Fitzpatrick at lyrasis.org Fri Feb 12 10:28:49 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Fri, 12 Feb 2016 15:28:49 +0000 Subject: [Archivesspace_Users_Group] UI and agent module feature requests In-Reply-To: <fa8af4b1ebfc475489b458b2451aadd4@ESGMTWEX6.win.ad.jhu.edu> References: <fa8af4b1ebfc475489b458b2451aadd4@ESGMTWEX6.win.ad.jhu.edu> Message-ID: <BL2PR08MB050C25ADA717847E51B549BFBA90@BL2PR08MB050.namprd08.prod.outlook.com> Hi, Thanks! Pull requests welcome! best, chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Jordon Steele <jsteele at jhu.edu> Sent: Friday, February 12, 2016 3:04 PM To: 'Archivesspace Users Group' Subject: [Archivesspace_Users_Group] UI and agent module feature requests Hi all, I wanted to direct your attention to my creation and support of the following feature requests. If they are of interest to you, too, I encourage you to vote for them. UI-related (mainly staff-side) ? "Expand all" and "collapse all" option in tree view: https://archivesspace.atlassian.net/browse/AS-82 ? Choose order of main fields in the Resources module: https://archivesspace.atlassian.net/browse/AS-81 ? Configure the search results screen: https://archivesspace.atlassian.net/browse/AR-996 ? Option of displaying the tree view for a resource record on the left (a la AT): https://archivesspace.atlassian.net/browse/AS-79 Agents ? Option to "show all resources/accessions" underneath a parent agent: https://archivesspace.atlassian.net/browse/AS-68 ? Option to "show all linked agents" in an agent record: https://archivesspace.atlassian.net/browse/AS-80 Best, Jordon Jordon Steele Hodson Curator of the University Archives The Sheridan Libraries Johns Hopkins University 3400 N Charles Street Baltimore, MD 21218 410-516-5493 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/4421c7bb/attachment.html> From j at minorscience.com Fri Feb 12 13:05:14 2016 From: j at minorscience.com (Jason Loeffler) Date: Fri, 12 Feb 2016 13:05:14 -0500 Subject: [Archivesspace_Users_Group] more ArchivesSpace screencasts up and your chance to participate In-Reply-To: <SN1PR08MB1967DB5331CB9D00413FF393F1D70@SN1PR08MB1967.namprd08.prod.outlook.com> References: <SN1PR08MB1967DB5331CB9D00413FF393F1D70@SN1PR08MB1967.namprd08.prod.outlook.com> Message-ID: <CAP4gJsXBkzEoSy_GS=nZ+dFG9hJcrg=uE63eFbr34t21X4_4mQ@mail.gmail.com> Hi Christine, I have some experience in this area, reasonably deep knowledge of the ArchivesSpace architecture, and would be happy to contribute a series of screencasts. I think it's a great resource for small and very small subscribing institutions that may not have much access to training and technical support. Can you tell me whether any of these topics are higher priority? All best, Jason Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York jason at minorscience.com (347) 405-0826 minorscience (Skype) On Wed, Feb 10, 2016 at 1:15 PM, Christine Di Bella < christine.dibella at lyrasis.org> wrote: > The video library for the ArchivesSpace User Screencast Series is growing! > As always, you can access the newest additions by logging in to the > authentication site at http://docs.archivesspace.org. Thanks to Christy > Tomecek, Angela Kroeger, and Kate Tasker for sharing their expertise with > the community in this round. > > > > There are still plenty of topics available, so if you?re willing to > demonstrate your ArchivesSpace knowledge ? whether you?re new to > ArchivesSpace or a total pro ? and earn a little extra cash at the same > time, take a look at the instructions for participating on the > ArchivesSpace wiki at > https://archivesspace.atlassian.net/wiki/display/ADC/Instructions+for+Creating+a+Video+for+the+ArchivesSpace+User+Screencast+Series. > Please get in touch if you?d like to record a screencast, or if you?d like > to suggest additional topics. > > > > Christine > > > > Christine Di Bella > > Community Outreach and Support Manager > > christine.dibella at lyrasis.org > > 800.999.8558 x2905 > > 678-235-2905 > > cdibella13 (Skype) > > [image: cid:image003.png at 01CE734E.FD759D30] > > > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/ff04664f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7645 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/ff04664f/attachment.png> From kspring at uci.edu Fri Feb 12 18:25:40 2016 From: kspring at uci.edu (Kelly Spring) Date: Fri, 12 Feb 2016 23:25:40 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> Message-ID: <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> UCI also supports AS-76. Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<http://special.lib.uci.edu/> From: Cyndi Shein [mailto:cyndi.shein at unlv.edu] Sent: Tuesday, February 09, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [https://docs.google.com/uc?export=download&id=0B2OzX83HDLhZQXF0eTVaRk1DNXM&revid=0B2OzX83HDLhZY1RYOS8xZVk5MGhYdTBlY1NlbUNFaUpYQm84PQ] unlvspecialcollections<https://www.facebook.com/unlvspecialcollections> [cid:image004.jpg at 01D165A9.9BD570F0] On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>> wrote: UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619<tel:858-534-5619> | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521<tel:617.495.8521> Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image005.png at 01D165A9.9BD570F0] Screenshot 2 [cid:image006.png at 01D165A9.9BD570F0] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503<tel:%28423%29%20425-4503> Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255<tel:%28650%29%20521-2255> | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713<tel:617.496.2713> voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982<tel:919-660-5982> http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573<tel:%28949%29%20824-6573> http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/02890996/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 2366 bytes Desc: image004.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/02890996/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 38864 bytes Desc: image005.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/02890996/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 49510 bytes Desc: image006.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160212/02890996/attachment-0001.png> From Chris.Fitzpatrick at lyrasis.org Mon Feb 15 03:49:57 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Mon, 15 Feb 2016 08:49:57 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com>, <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> Message-ID: <BY2PR08MB06324D15F8FBAFF302F5AF1FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> Hi All, 1. Also, just to mention if someone wants to send in a pull request to look at for this, it would really increase the chances of it being included in an upcoming release. best, chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Kelly Spring <kspring at uci.edu> Sent: Saturday, February 13, 2016 12:25 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UCI also supports AS-76. Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<http://special.lib.uci.edu/> [http://previous.lib.uci.edu/images/header-images/sca-header-images/speccoll-header-1.jpg]<http://special.lib.uci.edu/> Special Collections<http://special.lib.uci.edu/> special.lib.uci.edu Special Collections and Archives houses the UC Irvine Libraries' collections of rare books, manuscripts, archives, photographs, and other rare and special materials. From: Cyndi Shein [mailto:cyndi.shein at unlv.edu] Sent: Tuesday, February 09, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [https://docs.google.com/uc?export=download&id=0B2OzX83HDLhZQXF0eTVaRk1DNXM&revid=0B2OzX83HDLhZY1RYOS8xZVk5MGhYdTBlY1NlbUNFaUpYQm84PQ] unlvspecialcollections<https://www.facebook.com/unlvspecialcollections> [cid:image004.jpg at 01D165A9.9BD570F0] On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>> wrote: UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619<tel:858-534-5619> | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521<tel:617.495.8521> Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image005.png at 01D165A9.9BD570F0] Screenshot 2 [cid:image006.png at 01D165A9.9BD570F0] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503<tel:%28423%29%20425-4503> Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255<tel:%28650%29%20521-2255> | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713<tel:617.496.2713> voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982<tel:919-660-5982> http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573<tel:%28949%29%20824-6573> http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/99c534f3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 2366 bytes Desc: image004.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/99c534f3/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 38864 bytes Desc: image005.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/99c534f3/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 49510 bytes Desc: image006.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/99c534f3/attachment-0001.png> From kate_bowers at harvard.edu Mon Feb 15 11:35:07 2016 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Mon, 15 Feb 2016 16:35:07 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <BY2PR08MB06324D15F8FBAFF302F5AF1FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com>, <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com>, <BY2PR08MB06324D15F8FBAFF302F5AF1FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <SN1PR0701MB177519B98D34C5FB2754CFDE80AC0@SN1PR0701MB1775.namprd07.prod.outlook.com> What is a "pull request" who is authorized to "send one in" and how do they do that? Once you tell me these things, I will personally sit next to anyone who can execute a "pull request" and hurl $20 bills at them until the task is completed.* *offer not available in all areas, subject to change, but I will definitely buy you a beer/coffee Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787 fax: (617) 495-8011 kate_bowers at harvard.edu ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org> Sent: Monday, February 15, 2016 3:49 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi All, 1. Also, just to mention if someone wants to send in a pull request to look at for this, it would really increase the chances of it being included in an upcoming release. best, chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Kelly Spring <kspring at uci.edu> Sent: Saturday, February 13, 2016 12:25 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UCI also supports AS-76. Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> [http://previous.lib.uci.edu/images/header-images/sca-header-images/speccoll-header-1.jpg]<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> Special Collections<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> special.lib.uci.edu Special Collections and Archives houses the UC Irvine Libraries' collections of rare books, manuscripts, archives, photographs, and other rare and special materials. From: Cyndi Shein [mailto:cyndi.shein at unlv.edu] Sent: Tuesday, February 09, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [https://docs.google.com/uc?export=download&id=0B2OzX83HDLhZQXF0eTVaRk1DNXM&revid=0B2OzX83HDLhZY1RYOS8xZVk5MGhYdTBlY1NlbUNFaUpYQm84PQ] unlvspecialcollections<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_unlvspecialcollections&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=buzU5ikgX54NwC2hx6ovTVRyB07kBgt9fAnh-mkK944&e=> [cid:image004.jpg at 01D165A9.9BD570F0] On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>> wrote: UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619<tel:858-534-5619> | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521<tel:617.495.8521> Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image005.png at 01D165A9.9BD570F0] Screenshot 2 [cid:image006.png at 01D165A9.9BD570F0] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AS-2D76&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=QUpHD5feOr8PKWUU0jLrJOPTvrvpsMIrier1jCOIkvc&e=> (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503<tel:%28423%29%20425-4503> Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255<tel:%28650%29%20521-2255> | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713<tel:617.496.2713> voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982<tel:919-660-5982> http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573<tel:%28949%29%20824-6573> http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/e22fe3f5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 2366 bytes Desc: image004.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/e22fe3f5/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 38864 bytes Desc: image005.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/e22fe3f5/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 49510 bytes Desc: image006.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/e22fe3f5/attachment-0001.png> From megan.mummey at uky.edu Mon Feb 15 12:03:30 2016 From: megan.mummey at uky.edu (Mummey, Megan) Date: Mon, 15 Feb 2016 17:03:30 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> Message-ID: <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> UK also supports AS-76. Megan Mummey Collections Management Archivist Special Collections Research Center University of Kentucky Libraries Margaret I. King Library Lexington, KY 40506-0039 megan.mummey at uky.edu<mailto:Megan.mummey at uky.edu>|859.257.6942 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Friday, February 12, 2016 6:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UCI also supports AS-76. Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<http://special.lib.uci.edu/> From: Cyndi Shein [mailto:cyndi.shein at unlv.edu] Sent: Tuesday, February 09, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [https://docs.google.com/uc?export=download&id=0B2OzX83HDLhZQXF0eTVaRk1DNXM&revid=0B2OzX83HDLhZY1RYOS8xZVk5MGhYdTBlY1NlbUNFaUpYQm84PQ] unlvspecialcollections<https://www.facebook.com/unlvspecialcollections> [cid:image001.jpg at 01D167E8.D1071170] On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>> wrote: UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619<tel:858-534-5619> | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521<tel:617.495.8521> Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image002.png at 01D167E8.D1071170] Screenshot 2 [cid:image003.png at 01D167E8.D1071170] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503<tel:%28423%29%20425-4503> Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255<tel:%28650%29%20521-2255> | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713<tel:617.496.2713> voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982<tel:919-660-5982> http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573<tel:%28949%29%20824-6573> http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/35ea9851/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2366 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/35ea9851/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 38864 bytes Desc: image002.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/35ea9851/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 49510 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/35ea9851/attachment-0001.png> From Chris.Fitzpatrick at lyrasis.org Mon Feb 15 13:15:12 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Mon, 15 Feb 2016 18:15:12 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com>, <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> Message-ID: <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> Hi, I would definitely support in any attempts to throw $20 bills at people while working, especially if it's video taped. Yeah, a "pull request" is a way of submitting contributions to a project, usually referring to a Github pull request. You can read how to do one here : https://help.github.com/articles/using-pull-requests/ The "pull request welcome" mantra is encouragement for the community to become involved in the development process. It's also just the quickest way to get a feature you want implemented. Anyone can submit a pull request, but it does have to be accepted. For all feature requests ( including the one that is being request to have undone ), this is approved by the community via the features prioritization subteam and product owner. One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? It sounds like most of the requests are just wanting to have a pull-down for processing_status in the collection management section, or is there a hard requirement to have a database schema change here? I would warn against having the same functionality covered by multiple features, since this spreads the technical resources pretty thin and really over complicates things... Or this might be something that can be done as a plugin sponsored by some of the organizations requesting it. best, Chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Mummey, Megan <megan.mummey at uky.edu> Sent: Monday, February 15, 2016 6:03 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UK also supports AS-76. Megan Mummey Collections Management Archivist Special Collections Research Center University of Kentucky Libraries Margaret I. King Library Lexington, KY 40506-0039 megan.mummey at uky.edu<mailto:Megan.mummey at uky.edu>|859.257.6942 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Friday, February 12, 2016 6:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UCI also supports AS-76. Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573 http://special.lib.uci.edu<http://special.lib.uci.edu/> From: Cyndi Shein [mailto:cyndi.shein at unlv.edu] Sent: Tuesday, February 09, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... UNLV University Libraries supports AS-76 as well. Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [https://docs.google.com/uc?export=download&id=0B2OzX83HDLhZQXF0eTVaRk1DNXM&revid=0B2OzX83HDLhZY1RYOS8xZVk5MGhYdTBlY1NlbUNFaUpYQm84PQ] unlvspecialcollections<https://www.facebook.com/unlvspecialcollections> [cid:image001.jpg at 01D167E8.D1071170] On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>> wrote: UC San Diego concurs. The experience (and resulting complications with managing data effectively) that Anne describes below are identical to UC San Diego?s, and we too support AS-76. Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619<tel:858-534-5619> | ? l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Engelhart, Anne Sent: Tuesday, February 09, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Cc: Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to post Harvard University?s position on AS-76. I also posted it on JIRA, AS-76. (Here it is below.) Anne Engelhart Head, Collection Services Schlesinger Library, Radcliffe Institute 10 Garden St. Cambridge, MA 02138 617.495.8521<tel:617.495.8521> Restoration of processing status to collection management records in ArchivesSpace Summary Sometime during the past year, ArchivesSpace made a major change to its functionality. ? It eliminated the processing status from collection management records. ? The processing status and associated date were converted to ?event? records. This has created several problems for archivists at Harvard who rely on this information for workflow and reporting purposes including: ? The ?processing status? in all accessions migrated from the Archivists? Toolkit (AT) for which processing statuses were assigned now displays as ?Not specified? (see Screenshot 1). ? The conversion of processing status from a condition (or type) to an event overcomplicates what was previously a fairly straightforward piece of collection management information. Detailed discussion of issues There are three troubling issues associated with this change in functionality. 1. The first should be important to all archives: by converting the processing status to an event, the ArchivesSpace developers have changed the nature of the data. A status is not equivalent to an event, although they can be related. There is one and only one ?status? at any one time, but there can be multiple events. Events can lead to status changes. For example, two ?partially processed? events may or may not lead to a status of ?processed,? because it is entirely possible that three or more processing events might be needed to conclude that the status of the collection is ?processed.? In addition, some statuses may have no relation to an event. For example ?Unknown? is a possible processing status. Finally, how does an archivist identify ?unprocessed? accessions in this scenario? This is another ?non-event?. Are ArchivesSpace users expected to run a report on all accessions and look for those for which there is no ?processing? event? Since there are many possible event types, this seems counter-productive and unnecessarily complex. 2. The second issue is perhaps unique to Harvard albeit no less critical. The Harvard AT-to-AS migration did not create event records based on processing status. Instead, while our back-end data has processing status in it, these statuses are, troublingly, not visible to staff. Instead the processing status displays as ?not specified? (Screenshot 1). The same record in AT displays a processing status. (Screenshot 2) Screenshot 1 [cid:image002.png at 01D167E8.D1071170] Screenshot 2 [cid:image003.png at 01D167E8.D1071170] 3. Processing status is a critical piece of information that should be available to archivists for reporting on their accessions. In Harvard's current ArchivesSpace environment is that it is not possible to understand the scope and nature of our backlogs. The staff member who discovered this issue previously used the AT to readily determine the number of unprocessed accessions. While attempting to gather the same information from ArchivesSpace, the staff member found that it was not possible to achieve the same results with existing ArchivesSpace functionality. It is essential to the Harvard University ArchivesSpace user community that processing status be restored to its original functionality. The restoration of processing status to collection management records would: ? Allow archivists to report out on backlog and processing statistics; ? Assist archivists in resource allocation planning for grant proposals and yearly projects; and ? Make this data currently in the back-end of ArchivesSpace easily available to archivists As such, Harvard University ArchivesSpace user community supports the JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Monday, January 04, 2016 12:56 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Quick FYI update for anyone interested in this thread. After a couple of off-list discussions I decided to go ahead an create a new "feature request" ticket in JIRA requesting that the "Processing Status" field be restored to the Collection Management sub-record. The ticket can be viewed at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for forgetting to submit in the form of a user story!). If there are any questions, concerns, or clarifications that I can help with related to the request please let me know. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "MATTHEW R FRANCIS" <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 25, 2015 4:50:24 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Thank you Brad for your explanation for why the change occurred with the processing status field, and thank you Kate, Noah, and Carolyn for your additional thoughts and feedback. Based on all of the provided feedback I asked some of our staff to work/test the new functionality while trying to consider the intent behind the changes, our existing local workflows and collections metadata, and the abstract "what do we consider processing status to mean". Based on this examination of the new functionality we would like to provide the following feedback (many of which have already been stated in this email thread): * In regards to "an event record allows much more information to be associated with the event", it has been our local practice and belief that more nuanced processing information that would help researchers and staff better understand a finding aid/the physical collection should be recorded in a corresponding "Processing Information" note (which is informed by our interpretation of DACS 7.1.8). That said, we do appreciate that the event record allows for the capturing of some metadata that would be less relevant to researchers, and consequently a place where additional metadata could be recorded outside of the aforementioned note field. * After examining our "processing status" data and discussing the new functionality, we agree with Kate's observation that "events and processing statuses are not logical equivalents." Additionally, we also agree with Noah's comment "that a resource or accession will always have only one current status." * Additionally, based on our examination, we do not believe that is ideal or logical to separate "processing status" from collection management records that still include: "processing priority", "processing plan", and "processors". * Our local workflows appear to be at a high level similar to what Carolyn has reported, and along with the data we had already created to take advantage of the previous functionality, we also preferred the simplicity of the processing status being a simple drop-down selection in the collection management records. * Based on our local use the processing status field, along with the current status of the ASpace tool, we found it much easier to report on collection status and to locate appropriate collections projects for our workers with the previous functionality over the current. * Finally, we also echo Kate's sentiment in that we do not understand why the new event features requires the removal of the processing status from the collection management records and consequently wonder if there is any reason not to have both? Due to the above points we are of the opinion that if the new event features cannot be appropriately maintained while also having the processing status functionality reside in the collection management records, we would be in favor of a return to the previous functionality, or a new approach that is more similar to the previous functionality. With that said, we understand that our rationale for this request is largely based on our local understanding of the role of the processing status field, our local workflows, and and our existing data. Because of this we recognize that not all ASpace members might share our perspective, and consequently we welcome continued discussion on this subject as appropriate. Thank you again to everyone who have already participated in the conversation, and we hope that as a community we can reach a consensus on the best direction for us to proceed in the near future. Hope all of you have a wonderful Thanksgiving. -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Tuesday, November 24, 2015 2:12:09 PM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... We used the Processing Status field in the Collection Management module to track processing of our all our Resource records. It?s a little less complex than the data needed to populate an Event. I preferred the basic dropdown menu offered in Collection Management because it doesn?t require and Event Date/Time or a link it to an Agent. With legacy data, I won?t able to link an accurate Agent or Date to my processing events, which means I?ll have to devise some sort of input workaround for undated and anonymous Events. One last note, when Processing Status became and Event, Event Date/Time and Agent Links were populated, but they?re not accurate. They appear to reflect the Agent who selected the Processing Status and the Timestamp of when the Agent made the Processing Status selection. This means that if I want accurate data, I?ll need to clean up this legacy data. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503<tel:%28423%29%20425-4503> Dept. 6456, LIB 439D On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote: I tend to agree with Kate here. It seems useful to allow a resource or accession to have lots of processing events associated with it (who did what, when), but it also seems that a resource or accession will always have only one current status (processed, not processed, partially processed, etc.). Also, associated events do not display in ?edit? mode for resources or accessions (collection management sub-records do). As a result, it?s a bit complicated to figure out what the processing status is if you have to sort through a long list of associated events in ?view? mode. -Noah From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, November 19, 2015 9:40 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Brad, Thanks for your very thorough reply! I think you presented this as an either/or choice. However, because events and processing status are not logical equivalents (they may be associated in that the status may be the result of an event, but it does not have to be), I do not understand why adding features to the events record requires removal of the status. I short, is there any reason not to have both? Thanks again, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives Cambridge, Massachusetts, USA voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Brad Westbrook <brad.westbrook at lyrasis.org<mailto:brad.westbrook at lyrasis.org>> Sent: Wednesday, November 18, 2015 6:04:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi. Certainly it is possible and reasonable to have a discussion of how to adjust this change in functionality to make it more satisfying and less confusing, including reverting back to the functionality first included in ArchivesSpace. As I recall that functionality, it consisted of the ability to link a single collection management record to a material description record (accession, resource, or digital object but not components for resources and digital objects) and, further, to indicate in that collection management record the processing status of the material being described. Default terms were ?completed?, ?in_progress?, and ?new?, but the controlled value list was completely configurable. So institutions could add any terms they wanted to that list but they could only ever apply one status term to the material being described at a given time. We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent. We envisioned several benefits to this change: 1) As before, an organization has complete liberty to decide what terms it wants to use for expressing processing events and changes in processing status, as well as for any other events an institution chooses to track. The ?Event Event Type? list is completely configurable. 2) An event record allows much more information to be associated with the event, including a descriptive note about the event, when the event occurred, and who was responsible for the event. It struck us that knowing that processing of a collection was completed on a certain date and by a certain individual could be more useful information that know processing was simply completed. 3) Multiple event records can be associated to the same material description record. For instance, using event records it would be possible to indicate when processing of material started in one event record and when it was completed in another. 4) Multiple event records can be linked to component records. Thus for processing projects split into parallel parts, it would be possible to track, say, the processing progress of series. In short, our belief is that the collection management record in conjunction with event records provides a more comprehensive and flexible way for organizations to record collection management information. In that relationship, the collection management record is the location for planning?indicating processing priority, estimating processing time, indicating processing plan(s) and processor(s), but also noting funding source and whether rights are determined (it?s questionable whether or not these last two should be included in the collection management record)?while the event record is for recording completion (or not) of processing / administrative tasks associated with the materials?acquiring a purchase agreement, starting processing, completing processing, etc. There are requisites for this, of course: 1) Institutional policies regarding what events are to be tracked and what event vocabulary is to be used. 2) A process for creating and sharing reports that relate material descriptions, collection management, and events in meaningful ways. A segment of the ArchivesSpace community has been working to develop a reporting process, but the trajectory being taken will place the burden on institutions to define reports (You can, btw, see a record of this effort at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current work) andhttps://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past work). It was also noted in the ArchivesSpace developers meeting last week, that information of this type would be very suitable for displaying in a dashboard widget. Of course, institutions can already build their own reporting and define their own reports by using report software to extract and format data from the ArchivesSpace MySQL database. But these would be requisites for any collection management information, supplemented or not by event information. They would be requisites for a reversion for a return to the previous data model. Let me close with two observations to other parts of this thread: 1) The display problem that Noah noted in his comment yesterday is a remnant of moving collection status to events. There is a bug report requesting its correction at AR-1324<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>. 2) The presence of the ?Collection Management Processing Status? in the list of controlled values is also remnant of that change. It should be removed , unless there is a collective decision to revert. Thanks for pointing that out, Kelly. So it would be great to hear others weigh in on this. Collection management and event information have, as far as I know, no prevailing models or standards that we can simply follow. The closest to such is the de facto collection management sub-record created for accessions in the Archivists? Toolkit, which was generalized for all top-level material descriptions in ArchivesSpace and supplemented by the inclusion of events. The ArchivesSpace event module is itself an extension of the PREMIS events. Best, Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of MATTHEW R FRANCIS Sent: Wednesday, November 18, 2015 4:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... For the reasons outlined by Kate, and seconded by Glynn, we have also found this change rather confusing, and unfortunately it has hampered our ability to identify and report on various issues related to processing status, including the previously mentioned backlog issue. I do not know if this is an issue that others would like revisited, but from our perspective we would welcome a conversation on if there is better alternative moving forward (including possibly reverting back to the pre-v1.3 set-up). -Matt Matt Francis Archivist for Collection Management Special Collections Library Penn State University ________________________________ From: "Glynn Edwards" <gedwards at stanford.edu<mailto:gedwards at stanford.edu>> To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Sent: Wednesday, November 18, 2015 11:13:44 AM Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kate, We're on the same page...I too find this rather confusing. It is not straightforward enough for tracking status of collections across holdings easily. Cheers, Glynn Glynn Edwards Head, Technical Services Director, ePADD project Special Collections Stanford University Libraries Stanford, CA 94305-6064 (650) 521-2255<tel:%28650%29%20521-2255> | gedwards at stanford.edu<mailto:gedwards at stanford.edu> ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> Sent: Tuesday, November 17, 2015 1:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I am very confused. Can you explain how this is would work? How is an archivist supposed to understand an accession?s status from one or more associated ?events? rather than from a straightforward status? I can also see how this would make reporting out backlogs really difficult. The reason I ask is that I can see how an event can lead to a status, but it is entirely possible that a status may have no associated event. Furthermore, the same type of event may lead to different statuses. In brief, status is not the same as ?event?. I can think of a couple of examples to illustrate this: ? ?Unknown? can be a status, but it has no associated event ? ?Partially processed? can be both a status an event. However, if one ?partially processes? an accession once, then the accession remains partially processed. If one ?partially processes? again, it could be that the processing has been completed and the accession?s status is now ?processed? or it could be that the accession is still only ?partially processed? and that additional processing events will be necessary to reach a ?processed? status. Thanks, Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713<tel:617.496.2713> voice: (617) 384-7787<tel:%28617%29%20384-7787> fax: (617) 495-8011<tel:%28617%29%20495-8011> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman Sent: Tuesday, November 17, 2015 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hi Kelly, During a previous release (v1.3), I think Processing Status was moved from the collection management subrecord to an Event record. Here is a JIRA issue describing this change: https://archivesspace.atlassian.net/browse/AR-827<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> Here are some specifics: Remove ?Processing Status? Collection Management sub-record If data is present, migrate to Event record with these settings and linked to same record collection management sub-record is linked to: Type = ?Processing [Value in Collection Management Record for Processing Status]? Date/Time Specifier = ?Time stamp for last modification of Collection Management record? Label= Agent relationship Type=Single Role=Implementer Agent=ID of agent last modifying the collection management sub-record So, if you previously had processing status in a collection management subrecord, you might try browsing your event records to see if you can locate that data. Hope this helps, -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982<tel:919-660-5982> http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kelly Spring Sent: Tuesday, November 17, 2015 2:40 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... Hello! Our Processing Status field is visible when using the Manage Controlled Value Lists feature; but is not present when actually working within a collection management sub-record in an accession or resource. Any tips or advice out there? Thank you and have a great day! *Kelly Kelly Spring Archivist for Special Collections University of California, Irvine Libraries (949) 824-6573<tel:%28949%29%20824-6573> http://special.lib.uci.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/5c1eafed/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2366 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/5c1eafed/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 38864 bytes Desc: image002.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/5c1eafed/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 49510 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/5c1eafed/attachment-0001.png> From psuda1 at tulane.edu Mon Feb 15 13:26:01 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Mon, 15 Feb 2016 18:26:01 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Message-ID: <BN1PR03MB266541C13D60CE049175A0BE5AC0@BN1PR03MB266.namprd03.prod.outlook.com> Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a 'plugin' to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/a976fdb8/attachment.html> From j at minorscience.com Mon Feb 15 14:29:33 2016 From: j at minorscience.com (Jason Loeffler) Date: Mon, 15 Feb 2016 14:29:33 -0500 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <SN1PR0701MB177519B98D34C5FB2754CFDE80AC0@SN1PR0701MB1775.namprd07.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <BY2PR08MB06324D15F8FBAFF302F5AF1FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> <SN1PR0701MB177519B98D34C5FB2754CFDE80AC0@SN1PR0701MB1775.namprd07.prod.outlook.com> Message-ID: <CAP4gJsWpj2ADVomn446rhucHb3jrYjbTPWP4K_HjDeezva65eg@mail.gmail.com> A pull request is a request to make changes to the source code of a web application or other technology project. They are issued by developers to a version control system like GitHub. More here <https://help.github.com/articles/using-pull-requests/>. Any proposed changes made by contributing developer are reviewed and either merged or rejected by the code maintainer (in this case Lyrasis). Since ArchivesSpace is a community-drive, open-source project, pull requests afford an opportunity for developers from both within and outside of the ArchivesSpace community to develop and submit enhancements to the project. Hope that clarifies. Jason Loeffler Technology Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York jason at minorscience.com (347) 405-0826 minorscience (Skype) On Mon, Feb 15, 2016 at 11:35 AM, Bowers, Kate A. <kate_bowers at harvard.edu> wrote: > > > What is a "pull request" who is authorized to "send one in" and how do > they do that? > > > Once you tell me these things, I will personally sit next to anyone who > can execute a "pull request" and hurl $20 bills at them until the task is > completed.* > > > > > > > > *offer not available in all areas, subject to change, but I will > definitely buy you a beer/coffee > > Kate Bowers > Collections Services Archivist for Metadata, Systems, and Standards > Harvard University Archives > Cambridge, Massachusetts, USA > voice: (617) 384-7787 > fax: (617) 495-8011 > kate_bowers at harvard.edu > > > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org> > *Sent:* Monday, February 15, 2016 3:49 AM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Hi All, > > > > 1. Also, just to mention if someone wants to send in a pull request to > look at for this, it would really increase the chances of it being included > in an upcoming release. > > > best, chris. > > > Chris Fitzpatrick | Developer, ArchivesSpace > Skype: chrisfitzpat | Phone: 918.236.6048 > http://archivesspace.org/ > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Kelly Spring <kspring at uci.edu> > *Sent:* Saturday, February 13, 2016 12:25 AM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > UCI also supports AS-76. > > > > > > Kelly Spring > > Archivist for Special Collections > > University of California, Irvine Libraries > > (949) 824-6573 > > http://special.lib.uci.edu > <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> > Special Collections > <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=> > special.lib.uci.edu > Special Collections and Archives houses the UC Irvine Libraries' > collections of rare books, manuscripts, archives, photographs, and other > rare and special materials. > > > > > > > > *From:* Cyndi Shein [mailto:cyndi.shein at unlv.edu] > *Sent:* Tuesday, February 09, 2016 3:42 PM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > UNLV University Libraries supports AS-76 as well. > > > Cyndi Shein > > Head, Special Collections Technical Services > > University Libraries, University of Nevada, Las Vegas > > cyndi.shein at unlv.edu (702) 895-2223 > > > > unlvspecialcollections > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_unlvspecialcollections&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=buzU5ikgX54NwC2hx6ovTVRyB07kBgt9fAnh-mkK944&e=> > > > > On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu> > wrote: > > UC San Diego concurs. The experience (and resulting complications with > managing data effectively) that Anne describes below are identical to UC > San Diego?s, and we too support AS-76. > > > > *Laurel McPhee Dougherty* > > Supervisory Archivist, Special Collections & Archives Program > > UC San Diego Library | ( 858-534-5619 | * l1dougherty at ucsd.edu > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Engelhart, > Anne > *Sent:* Tuesday, February 09, 2016 8:58 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Cc:* Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu> > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > I?ve been asked by the Harvard ArchivesSpace Interim Steering Group to > post Harvard University?s position on AS-76. I also posted it on JIRA, > AS-76. (Here it is below.) > > > > Anne Engelhart > > Head, Collection Services > > Schlesinger Library, Radcliffe Institute > > 10 Garden St. > > Cambridge, MA 02138 > > 617.495.8521 > > > > *Restoration of processing status to collection management records in > ArchivesSpace* > > *Summary * > > Sometime during the past year, ArchivesSpace made a major change to its > functionality. > > ? It eliminated the processing status from collection management > records. > > ? The processing status and associated date were converted to > ?event? records. > > This has created several problems for archivists at Harvard who rely on > this information for workflow and reporting purposes including: > > ? The ?processing status? in all accessions migrated from the > Archivists? Toolkit (AT) for which processing statuses were assigned now > displays as ?Not specified? (see Screenshot 1). > > ? The conversion of processing status from a condition (or type) > to an event overcomplicates what was previously a fairly straightforward > piece of collection management information. > > *Detailed discussion of issues* > > There are three troubling issues associated with this change in > functionality. > > 1. The first should be important to all archives: by converting the > processing status to an event, the ArchivesSpace developers have changed > the nature of the data. A status is not equivalent to an event, although > they can be related. There is one and only one ?status? at any one time, > but there can be multiple events. Events can lead to status changes. For > example, two ?partially processed? events may or may not lead to a status > of ?processed,? because it is entirely possible that three or more > processing events might be needed to conclude that the status of the > collection is ?processed.? In addition, some statuses may have no relation > to an event. For example ?Unknown? is a possible processing status. > Finally, how does an archivist identify ?unprocessed? accessions in this > scenario? This is another ?non-event?. Are ArchivesSpace users expected to > run a report on all accessions and look for those for which there is no > ?processing? event? Since there are many possible event types, this seems > counter-productive and unnecessarily complex. > > > > 2. The second issue is perhaps unique to Harvard albeit no less > critical. The Harvard AT-to-AS migration did not create event records based > on processing status. Instead, while our back-end data has processing > status in it, these statuses are, troublingly, not visible to staff. > Instead the processing status displays as ?not specified? (Screenshot 1). > The same record in AT displays a processing status. (Screenshot 2) > > > > > > > > > > > > > > > > > > > > *Screenshot 1* > > *Screenshot 2* > > > > 3. Processing status is a critical piece of information that should > be available to archivists for reporting on their accessions. In Harvard's > current ArchivesSpace environment is that it is not possible to understand > the scope and nature of our backlogs. The staff member who discovered this > issue previously used the AT to readily determine the number of unprocessed > accessions. While attempting to gather the same information from > ArchivesSpace, the staff member found that it was not possible to achieve > the same results with existing ArchivesSpace functionality. > > > > It is essential to the Harvard University ArchivesSpace user community > that processing status be restored to its original functionality. The > restoration of processing status to collection management records would: > > ? Allow archivists to report out on backlog and processing > statistics; > > ? Assist archivists in resource allocation planning for grant > proposals and yearly projects; and > > ? Make this data currently in the back-end of ArchivesSpace > easily available to archivists > > As such, Harvard University ArchivesSpace user community supports the JIRA > ticket (AS-76) submitted by Matt Francis of Penn State Libraries. > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW > R FRANCIS > *Sent:* Monday, January 04, 2016 12:56 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Quick FYI update for anyone interested in this thread. After a couple of > off-list discussions I decided to go ahead an create a new "feature > request" ticket in JIRA requesting that the "Processing Status" field be > restored to the Collection Management sub-record. The ticket can be viewed > at: https://archivesspace.atlassian.net/browse/AS-76 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AS-2D76&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=QUpHD5feOr8PKWUU0jLrJOPTvrvpsMIrier1jCOIkvc&e=> (my > apologies for forgetting to submit in the form of a user story!). > > > > If there are any questions, concerns, or clarifications that I can help > with related to the request please let me know. > > > > -Matt > > > > *Matt** Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"MATTHEW R FRANCIS" <mrf22 at psu.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Wednesday, November 25, 2015 4:50:24 PM > *Subject: *Re: > [Archivesspace_Users_Group] Collection management - processing status > disappeared... > > > > Thank you Brad for your explanation for why the change occurred with the > processing status field, and thank you Kate, Noah, and Carolyn for your > additional thoughts and feedback. > > > > Based on all of the provided feedback I asked some of our staff to > work/test the new functionality while trying to consider the intent behind > the changes, our existing local workflows and collections metadata, and the > abstract "what do we consider processing status to mean". Based on this > examination of the new functionality we would like to provide the following > feedback (many of which have already been stated in this email thread): > > - In regards to "an event record allows much more information to be > associated with the event", it has been our local practice and belief that > more nuanced processing information that would help researchers and staff > better understand a finding aid/the physical collection should be recorded > in a corresponding "Processing Information" note (which is informed by our > interpretation of DACS 7.1.8). That said, we do appreciate that the event > record allows for the capturing of some metadata that would be less > relevant to researchers, and consequently a place where additional metadata > could be recorded outside of the aforementioned note field. > - After examining our "processing status" data and discussing the new > functionality, we agree with Kate's observation that "events and processing > statuses are not logical equivalents." Additionally, we also agree with > Noah's comment "that a resource or accession will always have only one > current status." > - Additionally, based on our examination, we do not believe that is > ideal or logical to separate "processing status" from collection management > records that still include: "processing priority", "processing plan", and > "processors". > - Our local workflows appear to be at a high level similar to what > Carolyn has reported, and along with the data we had already created to > take advantage of the previous functionality, we also preferred the > simplicity of the processing status being a simple drop-down selection in > the collection management records. > - Based on our local use the processing status field, along with the > current status of the ASpace tool, we found it much easier to report on > collection status and to locate appropriate collections projects for our > workers with the previous functionality over the current. > - Finally, we also echo Kate's sentiment in that we do not understand > why the new event features requires the removal of the processing status > from the collection management records and consequently wonder if there is > any reason not to have both? > > Due to the above points we are of the opinion that if the new event > features cannot be appropriately maintained while also having the > processing status functionality reside in the collection management > records, we would be in favor of a return to the previous functionality, or > a new approach that is more similar to the previous functionality. With > that said, we understand that our rationale for this request is largely > based on our local understanding of the role of the processing status > field, our local workflows, and and our existing data. Because of this we > recognize that not all ASpace members might share our perspective, and > consequently we welcome continued discussion on this subject as appropriate. > > > > Thank you again to everyone who have already participated in the > conversation, and we hope that as a community we can reach a consensus on > the best direction for us to proceed in the near future. > > > > Hope all of you have a wonderful Thanksgiving. > > > > -Matt > > > > *Matt** Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"Runyon, Carolyn" <Carolyn-Runyon at utc.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Tuesday, November 24, 2015 2:12:09 PM > *Subject: *Re: > [Archivesspace_Users_Group] Collection management - processing status > disappeared... > > > > We used the Processing Status field in the Collection Management module to > track processing of our all our Resource records. It?s a little less > complex than the data needed to populate an Event. I preferred the basic > dropdown menu offered in Collection Management because it doesn?t require > and Event Date/Time or a link it to an Agent. With legacy data, I won?t > able to link an accurate Agent or Date to my processing events, which means > I?ll have to devise some sort of input workaround for undated and anonymous > Events. > > > > One last note, when Processing Status became and Event, Event Date/Time > and Agent Links were populated, but they?re not accurate. They appear to > reflect the Agent who selected the Processing Status and the Timestamp of > when the Agent made the Processing Status selection. This means that if I > want accurate data, I?ll need to clean up this legacy data. > > > > Cheers, > > Carolyn > > > > > > > > Carolyn Runyon > Assistant Head of Collection Services and Director of Special Collections > University of Tennessee at Chattanooga Library > 615 McCallie Ave., Chattanooga, TN 37403 > Carolyn-Runyon at utc.edu, (423) 425-4503 > Dept. 6456, LIB 439D > > > > On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu> wrote: > > I tend to agree with Kate here. It seems useful to allow a resource or > accession to have lots of processing events associated with it (who did > what, when), but it also seems that a resource or accession will always > have only one current status (processed, not processed, partially > processed, etc.). > > > > Also, associated events do not display in ?edit? mode for resources or > accessions (collection management sub-records do). As a result, it?s a bit > complicated to figure out what the processing status is if you have to sort > through a long list of associated events in ?view? mode. > > > > -Noah > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Bowers, > Kate A. > *Sent:* Thursday, November 19, 2015 9:40 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > > Brad, > > Thanks for your very thorough reply! > > I think you presented this as an either/or choice. However, because > events and processing status are not logical equivalents (they may be > associated in that the status may be the result of an event, but it does > not have to be), I do not understand why adding features to the events > record requires removal of the status. I short, is there any reason not to > have both? > > Thanks again, > > Kate > > Kate Bowers > Collections Services Archivist for Metadata, Systems, and Standards > Harvard University Archives > Cambridge, Massachusetts, USA > voice: (617) 384-7787 > fax: (617) 495-8011 > kate_bowers at harvard.edu > ------------------------------ > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Brad Westbrook <brad.westbrook at lyrasis.org> > *Sent:* Wednesday, November 18, 2015 6:04:27 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Hi. > > > > Certainly it is possible and reasonable to have a discussion of how to > adjust this change in functionality to make it more satisfying and less > confusing, including reverting back to the functionality first included in > ArchivesSpace. > > > > As I recall that functionality, it consisted of the ability to link a > single collection management record to a material description record > (accession, resource, or digital object but not components for resources > and digital objects) and, further, to indicate in that collection > management record the processing status of the material being described. > Default terms were ?completed?, ?in_progress?, and ?new?, but the > controlled value list was completely configurable. So institutions could > add any terms they wanted to that list but they could only ever apply one > status term to the material being described at a given time. > > > > We removed this field from the collection management field with the > understanding such data would be better handled as event information and > with the understanding that a change in status is first an event > accomplished at a time and by an agent. We envisioned several benefits to > this change: > > > > 1) As before, an organization has complete liberty to decide what > terms it wants to use for expressing processing events and changes in > processing status, as well as for any other events an institution chooses > to track. The ?Event Event Type? list is completely configurable. > > > > 2) An event record allows much more information to be associated > with the event, including a descriptive note about the event, when the > event occurred, and who was responsible for the event. It struck us that > knowing that processing of a collection was completed on a certain date and > by a certain individual could be more useful information that know > processing was simply completed. > > > > 3) Multiple event records can be associated to the same material > description record. For instance, using event records it would be possible > to indicate when processing of material started in one event record and > when it was completed in another. > > > > 4) Multiple event records can be linked to component records. Thus > for processing projects split into parallel parts, it would be possible to > track, say, the processing progress of series. > > > > In short, our belief is that the collection management record in > conjunction with event records provides a more comprehensive and flexible > way for organizations to record collection management information. In that > relationship, the collection management record is the location for > planning?indicating processing priority, estimating processing time, > indicating processing plan(s) and processor(s), but also noting funding > source and whether rights are determined (it?s questionable whether or not > these last two should be included in the collection management > record)?while the event record is for recording completion (or not) of > processing / administrative tasks associated with the materials?acquiring a > purchase agreement, starting processing, completing processing, etc. > > > > There are requisites for this, of course: > > > > 1) Institutional policies regarding what events are to be tracked > and what event vocabulary is to be used. > > > > 2) A process for creating and sharing reports that relate material > descriptions, collection management, and events in meaningful ways. A > segment of the ArchivesSpace community has been working to develop a > reporting process, but the trajectory being taken will place the burden on > institutions to define reports (You can, btw, see a record of this effort > at https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=> (current > work) and > https://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=> (past > work). It was also noted in the ArchivesSpace developers meeting last week, > that information of this type would be very suitable for displaying in a > dashboard widget. Of course, institutions can already build their own > reporting and define their own reports by using report software to extract > and format data from the ArchivesSpace MySQL database. > > > > But these would be requisites for any collection management information, > supplemented or not by event information. They would be requisites for a > reversion for a return to the previous data model. > > > > Let me close with two observations to other parts of this thread: > > > > 1) The display problem that Noah noted in his comment yesterday is a > remnant of moving collection status to events. There is a bug report > requesting its correction at AR-1324 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=> > . > > > > 2) The presence of the ?Collection Management Processing Status? in > the list of controlled values is also remnant of that change. It should be > removed , unless there is a collective decision to revert. Thanks for > pointing that out, Kelly. > > > > So it would be great to hear others weigh in on this. Collection > management and event information have, as far as I know, no prevailing > models or standards that we can simply follow. The closest to such is the > de facto collection management sub-record created for accessions in the > Archivists? Toolkit, which was generalized for all top-level material > descriptions in ArchivesSpace and supplemented by the inclusion of events. > The ArchivesSpace event module is itself an extension of the PREMIS events. > > > > Best, > > > > Brad W. > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *MATTHEW > R FRANCIS > *Sent:* Wednesday, November 18, 2015 4:49 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > For the reasons outlined by Kate, and seconded by Glynn, we have also > found this change rather confusing, and unfortunately it has hampered our > ability to identify and report on various issues related to processing > status, including the previously mentioned backlog issue. > > > > I do not know if this is an issue that others would like revisited, but > from our perspective we would welcome a conversation on if there is better > alternative moving forward (including possibly reverting back to the > pre-v1.3 set-up). > > > > -Matt > > > > *Matt** Francis* > > Archivist for Collection Management > > Special Collections Library > Penn State University > > > ------------------------------ > > *From: *"Glynn Edwards" <gedwards at stanford.edu> > *To: *"Archivesspace Users Group" < > archivesspace_users_group at lyralists.lyrasis.org> > *Sent: *Wednesday, November 18, 2015 11:13:44 AM > *Subject: *Re: [Archivesspace_Users_Group] > Collection management - processing status > disappeared... > > > > Hi Kate, > > We're on the same page...I too find this rather confusing. It is not > straightforward enough for tracking status of collections across holdings > easily. > > Cheers, > > Glynn > > > > Glynn Edwards > Head, Technical Services > Director, ePADD project > Special Collections > Stanford University Libraries > Stanford, CA 94305-6064 > (650) 521-2255 | gedwards at stanford.edu > > > ------------------------------ > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Bowers, Kate A. <kate_bowers at harvard.edu> > *Sent:* Tuesday, November 17, 2015 1:08 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > I am very confused. Can you explain how this is would work? How is an > archivist supposed to understand an accession?s status from one or more > associated ?events? rather than from a straightforward status? I can also > see how this would make reporting out backlogs really difficult. > > > > The reason I ask is that I can see how an event can lead to a status, but > it is entirely possible that a status may have no associated event. > Furthermore, the same type of event may lead to different statuses. > > > > In brief, status is not the same as ?event?. I can think of a couple of > examples to illustrate this: > > ? ?Unknown? can be a status, but it has no associated event > > ? ?Partially processed? can be both a status an event. However, > if one ?partially processes? an accession once, then the accession remains > partially processed. If one ?partially processes? again, it could be that > the processing has been completed and the accession?s status is now > ?processed? or it could be that the accession is still only ?partially > processed? and that additional processing events will be necessary to reach > a ?processed? status. > > > > Thanks, > > > > Kate > > > > > > *Kate Bowers* > > Collections Services Archivist for Metadata, Systems, and Standards > > Harvard University Archives > > kate_bowers at harvard.edu <megan_sniffin-marinoff at harvard.edu> > > 617.496.2713 > > voice: (617) 384-7787 > > fax: (617) 495-8011 > > web: http://nrs.harvard.edu/urn-3:hul.eresource:archives > > Twitter: @k8_bowers > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Noah > Huffman > *Sent:* Tuesday, November 17, 2015 3:01 PM > *To:* Archivesspace Users Group > *Subject:* Re: [Archivesspace_Users_Group] Collection management - > processing status disappeared... > > > > Hi Kelly, > > > > During a previous release (v1.3), I think Processing Status was moved from > the collection management subrecord to an Event record. Here is a JIRA > issue describing this change: > https://archivesspace.atlassian.net/browse/AR-827 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=> > > > > Here are some specifics: > > Remove ?Processing Status? Collection Management sub-record > > If data is present, migrate to Event record with these settings and linked > to same record collection management sub-record is linked to: > > > > Type = ?Processing [Value in Collection Management Record for Processing > Status]? > > > > Date/Time Specifier = ?Time stamp for last modification of Collection > Management record? > > > > Label= Agent relationship > > > > Type=Single > > > > Role=Implementer > > > > Agent=ID of agent last modifying the collection management sub-record > > > > > > So, if you previously had processing status in a collection management > subrecord, you might try browsing your event records to see if you can > locate that data. > > > > Hope this helps, > > > > -Noah > > > > ================ > > Noah Huffman > > Archivist for Metadata, Systems, and Digital Records > > David M. Rubenstein Rare Book & Manuscript Library > > Duke University | 919-660-5982 > > http://library.duke.edu/rubenstein/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=> > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Kelly > Spring > *Sent:* Tuesday, November 17, 2015 2:40 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* [Archivesspace_Users_Group] Collection management - processing > status disappeared... > > > > Hello! > > > > Our Processing Status field is visible when using the Manage Controlled > Value Lists feature; but is not present when actually working within a > collection management sub-record in an accession or resource. Any tips or > advice out there? > > > > Thank you and have a great day! > > *Kelly > > > > > > > > > > Kelly Spring > > Archivist for Special Collections > > University of California, Irvine Libraries > > (949) 824-6573 > > http://special.lib.uci.edu > <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=> > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=> > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&e=> > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&e=> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 38864 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 49510 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 2366 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment.jpg> From akroeger at unomaha.edu Tue Feb 16 11:22:45 2016 From: akroeger at unomaha.edu (Angela Kroeger) Date: Tue, 16 Feb 2016 16:22:45 +0000 Subject: [Archivesspace_Users_Group] Certainty in date subrecord reverts to default Message-ID: <DM2PR07MB973FE9160C27EB8D8CB2DBBD3AD0@DM2PR07MB973.namprd07.prod.outlook.com> I am no longer able to change the certainty of the date in the date subrecord. We have "approximate" set as the default certainty for our date subrecords. When a date is certain, I change that to blank in the drop box. It has worked fine in all types of records until this morning. As of today, when I try to change that "approximate" to blank, it reverts to "approximate" after I save the record. With an archival object record, it changes back to "approximate" immediately after I save the record. With resource records and digital object records, it appears to save my changes, but if I refresh the screen or otherwise exit and return to the record, then it's "approximate" again. Worse, in some records that I had previously saved the certainty as blank (verified by it being blank on an old printout), the certainty has changed to "approximate" apparently with no one editing the record to be that way. I wondered if it were just something with my login or my browser, but I had someone else try to edit the same record on a different computer under a different user login, and she had the same thing happen. Anyone else experiencing this? We are on ArchivesSpace 1.4.2. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 12167 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/27035de8/attachment.bin> From psuda1 at tulane.edu Tue Feb 16 11:26:42 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Tue, 16 Feb 2016 16:26:42 +0000 Subject: [Archivesspace_Users_Group] Altering ASpace Public Formats Plugin Message-ID: <BN1PR03MB266D3CBCA543B252BF2B652E5AD0@BN1PR03MB266.namprd03.prod.outlook.com> Greetings all, How would one go about editing the way that EAD_PDFs are generated using the Aspace Public Formats plugin? I want to alter how the title is generated, etc. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/809d65dc/attachment.html> From psuda1 at tulane.edu Tue Feb 16 12:08:45 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Tue, 16 Feb 2016 17:08:45 +0000 Subject: [Archivesspace_Users_Group] Custom Javascript for Public Interface Message-ID: <BN1PR03MB2668DD75AE95913C52B9E7AE5AD0@BN1PR03MB266.namprd03.prod.outlook.com> Greetings all, Dumb question, but where can we place custom javascript/jquery files within the ArchivesSpace directory for use on the public interface? I have tried in footer files as well as in the assets/javascripts folder but it does not seem to be picked up. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/afe01592/attachment.html> From j at minorscience.com Tue Feb 16 13:55:15 2016 From: j at minorscience.com (Jason Loeffler) Date: Tue, 16 Feb 2016 18:55:15 +0000 (UTC) Subject: [Archivesspace_Users_Group] Components not loading in Public UI In-Reply-To: <CAPJRQSW2ZiWeu8b_SHZA8Z-M8WNzujMxBedKFUKeyTOZq4UDdA@mail.gmail.com> References: <CAPJRQSUo9R+Y=te0G7u8FBnyYs1WjuVpT_hbXHRzSKxhJJogCw@mail.gmail.com> <CAP4gJsWnhKh7pKpZ7V2ictfksjTRtaCR3nX8ktK1713WbDNMKQ@mail.gmail.com> <6568E68D6B5225458D97A8685E972C570AEB7EACF1@Exch2K7.strongmuseum.org> <CAP4gJsVkQwJ5=xTG8UCrqgQZMEDm-TCqqSwbao+iiVOXA1+u6A@mail.gmail.com> <CAPJRQSW2ZiWeu8b_SHZA8Z-M8WNzujMxBedKFUKeyTOZq4UDdA@mail.gmail.com> Message-ID: <E0903B9C708FD3BF.5B2517BC-592D-44D5-A709-53762E44D945@mail.outlook.com> Helen,? Are you or a system administrator able to access the log output file? Contact me off board is you like at jason at minorscience.com.? Jason On Thu, Feb 11, 2016 at 2:14 PM -0800, "Helen Thomas" <helen.thomas at nicholls.edu> wrote: Hi Jason, The URL for our public interface is?archives.nicholls.edu. Currently it is accessible only on our campus. I followed the directions to re-index and nothing changed.? I'm also getting this 404 Error when I do inspect element on any of the public interface collection pages:?GET http://archives.nicholls.edu/staff/tree?uri=%2Frepositories%2F2%2Fresources%2F21 404 (Not Found) Helen On Thu, Feb 11, 2016 at 3:03 PM, Jason Loeffler <j at minorscience.com> wrote: I'm not sure whether rebuilding the index?would help but it's worth a shot. Is that something your team can try?? On Thu, Feb 11, 2016 at 3:08 PM, Novakovic, Julia <jNovakovic at museumofplay.org> wrote: Hi Jason, ? The Strong has also been having this same issue [Components not appearing] with the Public Interface, just with our newly-created records. [All the data which migrated from Archivists? Toolkit came over fine and appears correctly in the Public Interface.] Looks like we are running Version v1.1.2. I?ve attached a previous email chain that I sent to the listserv. ? Thanks! --Julia ? ? ? Julia Novakovic Archivist Associate Editor, American Journal of Play The Strong One Manhattan Square Rochester, NY 14607 U.S.A. Tel 585-410-6307 Fax 585-423-1886 jnovakovic at museumofplay.org www.museumofplay.org ? The Strong is home to: International Center for the History of Electronic Games?| National Toy Hall of Fame | World Video Game Hall of Fame Brian Sutton-Smith Library and Archives of Play |?Woodbury School | American Journal of Play ? ? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jason Loeffler Sent: Thursday, February 11, 2016 3:01 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Components not loading in Public UI ? Helen, ? Can you tell me your ArchivesSpace version number?? ? Are you unable to view records from both the staff interface and the public interface? Does it affect all records or just newly created records? ? Jason Loeffler Technology?Consultant The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York ? ? On Thu, Feb 11, 2016 at 2:41 PM, Helen Thomas <helen.thomas at nicholls.edu> wrote: Hello all, ? I'm experiencing a problem where none of the components for my resource records are loading in the public interface. Instead, I get a perpetual loading GIF that never goes away. I noticed this after I attempted to add components to a couple of records. At first I thought that just those records had crashed (one now shows a completely blank screen for the staff side of the record in either edit or view mode), but after checking I found that none of my resource components are loading. We have recently upgraded to a production server, but the tech at campus IT believes this component issue to be software related. ? Does anyone have an idea what may be going on or how to address this problem? ? Best, Helen ? -- Helen Thomas Assistant Archivist Ellender Library, Nicholls State University? helen.thomas at nicholls.edu | (985) 448-4644 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group ? ---------- Forwarded message ---------- From:?"Novakovic, Julia" <jNovakovic at museumofplay.org> To:?Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Cc:?"Rugaber, Ross" <RRugaber at museumofplay.org> Date:?Tue, 1 Dec 2015 16:25:12 -0500 Subject:?Re: [Archivesspace_Users_Group] component trees not appearing in public view of AS Hi all, ? I wrote several weeks ago to the ArchivesSpace listserv to see if there was an easy fix for our issue of the hand-entered resource component tree and related record components not appearing on the public side of AS. I have made sure that all the correct fields are marked to ?Publish? and I also tried clicking ?Publish All? from the internal side of the main resource record, but to no avail. ? >From the public side, I right-clicked on the page and selected ?Inspect element? to see if it would tell me what the error actually is. Screenshot of the errors attached. ? Our Director of IT noted that it was coming up as a server side error, but he has tried over the last few weeks to determine what that error might be, if it?s on our end. He searched the AS forum but couldn?t find any answers there either. Does anyone have any other advice? ? Thank you in advance! --Julia ? ? Julia Novakovic Archivist Associate Editor, American Journal of Play The Strong One Manhattan Square Rochester, NY 14607 U.S.A. Tel 585-410-6307 Fax 585-423-1886 jnovakovic at museumofplay.org www.museumofplay.org ? The Strong is home to: International Center for the History of Electronic Games?| National Toy Hall of Fame | World Video Game Hall of Fame Brian Sutton-Smith Library and Archives of Play |?Woodbury School | American Journal of Play ? ? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Monday, November 02, 2015 5:02 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] component trees not appearing in public view of AS ? Hi, Julia, ? Is it possible that the components are not marked to be published? ? ? ? If not, you can A) indicate each component ?in the tree you want to publish to the public interface or B) select the ?Publish All? option on the parent record, which will publish everything in the description.? ? ? ? Let us know if that does work. ? Cheers, ? Brad W. ? Bradley D. Westbrook Program Manager brad.westbrook at lyrasis.org 800.999.8558 x2910 678.235.2910 bradley_d_westbrook (Skype)? ? ? ? ? ? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Novakovic, Julia Sent: Monday, November 02, 2015 1:20 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] component trees not appearing in public view of AS ? Hello, ? My institution had about 50 full resource records in Archivists? Toolkit which mapped/migrated perfectly over to ArchivesSpace earlier this year. However, I?m having an issue with the resources I?ve hand-entered into AS since then; the component trees appear fine in the internal side, but in the public view, there is just a three-bar churning ?icon there. Does anyone have any advice on what needs to happen so that all of our resources? components appear in the public view? [Screenshots comparing the two (public-side view) attached.] There is nothing else missing from the internal side to the public side for the newly hand-entered records, and I have tried clicking ?Publish All? to no avail. ? ? Related: Keyword searching in the internal side works perfectly for discovery of these hand-entered records. When I go to the public view, though, I will get the same search results, but when I click on any of those file records, I get the error message ?We?re sorry, but something went wrong.? Does this mean something isn?t linking correctly? I?d appreciate any advice that I can pass along to our Director of IT to fix the problem. ? Thanks! --Julia ? ? Julia Novakovic Archivist Associate Editor, American Journal of Play The Strong One Manhattan Square Rochester, NY 14607 U.S.A. Tel 585-410-6307 Fax 585-423-1886 jnovakovic at museumofplay.org www.museumofplay.org ? The Strong is home to: International Center for the History of Electronic Games?| National Toy Hall of Fame | World Video Game Hall of Fame Brian Sutton-Smith Library and Archives of Play |?Woodbury School | American Journal of Play ? _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Helen ThomasAssistant ArchivistEllender Library, Nicholls State University?helen.thomas at nicholls.edu | (985) 448-4644 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/c7c202c6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 7640 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/c7c202c6/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1137 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/c7c202c6/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 13275 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/c7c202c6/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 11388 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/c7c202c6/attachment-0001.jpg> From Carolyn-Runyon at utc.edu Tue Feb 16 16:18:04 2016 From: Carolyn-Runyon at utc.edu (Runyon, Carolyn) Date: Tue, 16 Feb 2016 21:18:04 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> Chris, I?m going to answer two of the questions you posed in yesterday?s email according to UTC?s preference. * Yes, we would like to see processing event records migrated back to their original collection_management records and then removed. * Yes, we like to see processing tracked in collection_management only and have it removed as an option in events. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160216/8c4d1084/attachment.html> From kristen.swett at boston.gov Wed Feb 17 10:08:59 2016 From: kristen.swett at boston.gov (Kristen Swett) Date: Wed, 17 Feb 2016 10:08:59 -0500 Subject: [Archivesspace_Users_Group] Public Interface question Message-ID: <CAAHTn+6BnHEgbZi9gaqonrY5XUKc0J=7kyrQcSOZS52yRa__vQ@mail.gmail.com> We have linked agents to archival objects in a resource as both creators and subjects. In the public interface, when the public chooses one of these names, it shows that there are no related collections. Is there a way to change this so that the public interface will show both related collections and components as it does with the Subjects? Thank you! *Kristen Swett* *Collections Manager* *City of Boston Archives* *201 Rivermoor Street* *West Roxbury, MA 02132* *617-635-1195* *fax: 617-635-1194* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/85860e68/attachment.html> From kate_bowers at harvard.edu Wed Feb 17 11:29:39 2016 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Wed, 17 Feb 2016 16:29:39 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> Message-ID: <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> I?m not sure that incorporating ?reverse migration? for all into re-establishing the disappeared functionality would be wise. Rather a one-time ?reversion helper? plug-in, that can be optionally executed by an ArchivesSpace repository, is better. Here?s my thinking 1) Less work means more likelihood of getting the basic, vital functionality of ?processing status? back into collection management records more quickly. By this I mean: the table is still there with the data in it (at least for AT migrations). Just put it back into the interface and for users and admins. 2) Status does not equal event. Status *may* be inferred from *some* events. 3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes. 4) Individual implementers may not need ?reverse migration? and the labor might be in excess of the work needed to simply apply processing statuses to accessions by hand. Questions to evaluate the need include: a) How much work would be involved in creating ?reverse migration?? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing status may not be that labor-intensive?it could be that not many accessions have been processed between migration and implementation. c) Did Archon have processing status? If so, were they also retained? d) How many repositories changed the default drop-downs for event records? Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Runyon, Carolyn Sent: Tuesday, February 16, 2016 4:18 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Chris, I?m going to answer two of the questions you posed in yesterday?s email according to UTC?s preference. * Yes, we would like to see processing event records migrated back to their original collection_management records and then removed. * Yes, we like to see processing tracked in collection_management only and have it removed as an option in events. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/5d930c2d/attachment.html> From prom at illinois.edu Wed Feb 17 11:42:51 2016 From: prom at illinois.edu (Prom, Christopher John) Date: Wed, 17 Feb 2016 16:42:51 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> Message-ID: <39878E9C-72E9-422F-8E55-5DA59628EED7@illinois.edu> Kate, To answer the archon specific question, it did not have that a processing status field (although I agree it would have been very helpful if it had!) Archon has a ?processing priority value and the ?processing status? could be inferred, to a certain extent from the relationship between the ?received extent? and ?unprocessed extent? fields on Archon's accession record. For example, if the former was set to 10 CF and the latter to 0 CF, you could infer it was processed. But these latter values were never heavily used in Archon even here at Illinois, and the migration tool does not migrate them, since at the time I developed the mapping I could not figure out a good way to handle them. Since no one has never asked me why they are missing, I assume the strategy of not migrating them made a certain amount of sense ;) Chris Prom On Feb 17, 2016, at 10:29 AM, Bowers, Kate A. <kate_bowers at harvard.edu<mailto:kate_bowers at harvard.edu>> wrote: I?m not sure that incorporating ?reverse migration? for all into re-establishing the disappeared functionality would be wise. Rather a one-time ?reversion helper? plug-in, that can be optionally executed by an ArchivesSpace repository, is better. Here?s my thinking 1) Less work means more likelihood of getting the basic, vital functionality of ?processing status? back into collection management records more quickly. By this I mean: the table is still there with the data in it (at least for AT migrations). Just put it back into the interface and for users and admins. 2) Status does not equal event. Status *may* be inferred from *some* events. 3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes. 4) Individual implementers may not need ?reverse migration? and the labor might be in excess of the work needed to simply apply processing statuses to accessions by hand. Questions to evaluate the need include: a) How much work would be involved in creating ?reverse migration?? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing status may not be that labor-intensive?it could be that not many accessions have been processed between migration and implementation. c) Did Archon have processing status? If so, were they also retained? d) How many repositories changed the default drop-downs for event records? Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Runyon, Carolyn Sent: Tuesday, February 16, 2016 4:18 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Chris, I?m going to answer two of the questions you posed in yesterday?s email according to UTC?s preference. * Yes, we would like to see processing event records migrated back to their original collection_management records and then removed. * Yes, we like to see processing tracked in collection_management only and have it removed as an option in events. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/bfbeccc0/attachment.html> From l1dougherty at ucsd.edu Wed Feb 17 14:33:40 2016 From: l1dougherty at ucsd.edu (Dougherty, Laurel) Date: Wed, 17 Feb 2016 19:33:40 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> Message-ID: <3975740D6A5FF946B2A77B95A7B228D7225C0226@xmail-mbx-bv1.AD.UCSD.EDU> I think Kate's approach sounds good. If the processing_status_id / cataloged fields and their related dates that are currently showing as Events can simply be made to reappear (populated with the data they contain) in the Collection Management subrecord (and Kate implies it's actually already there in the tables), then we're not necessarily proposing a sweeping deletion of folks' data or a change to the data model-just a restoration of functionality that has been the focus of this conversation. Perhaps this could happen in a sequence of events like this: 1) Following a pull request and prioritization/acceptance, a future version of ASpace is released with processing and cataloged status options (pull-down menus) and the other requisite fields that go along with them back in the Collection Management subrecord. Updating to this version doesn't cause anyone to lose data-it just reappears as it was originally migrated. 2) The migration tool is re-configured, for those who aren't in production yet, to have their AT processing status data mapped to the Collections Management subrecord 3) Institutions that want to wipe out their processing-related events can do so; if a plug-in is required to transfer data added to the Events module (post-migration), that is developed as a final step It's easy to configure the events by adding and deleting fields to fit your needs. So I wouldn't propose a reverse migration that wipes out processing events for everyone-after all, while re-reading Brad's post on this topic from November, this change was done with good intentions and was a deliberate extension of the PREMIS events model. I quote Brad here: "We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent." Some repositories may very well want to continue adding processing actions as events (i.e. "partially processed" by [agent] on [date]) to allow for granular reports on these types of events and agents in the future. But it seems, in addition, institutions simply want an option via Collection Management to say: is this stuff processed, or not? Because an event is not necessarily the same as a status. As others have pointed out, a status is just easier for querying and on-the-ground collection management. A one-time version change that exposes those relevant fields that were moved to Events and plops them back into the Collection Management subrecord might be a suitable minimum "do no harm" approach. Plug-ins to migrate data between the Events and Collections Management subrecords might be a slightly different issue. Respectfully, Laurel Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | * 858-534-5619 | * l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Wednesday, February 17, 2016 8:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I'm not sure that incorporating "reverse migration" for all into re-establishing the disappeared functionality would be wise. Rather a one-time "reversion helper" plug-in, that can be optionally executed by an ArchivesSpace repository, is better. Here's my thinking 1) Less work means more likelihood of getting the basic, vital functionality of "processing status" back into collection management records more quickly. By this I mean: the table is still there with the data in it (at least for AT migrations). Just put it back into the interface and for users and admins. 2) Status does not equal event. Status *may* be inferred from *some* events. 3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes. 4) Individual implementers may not need "reverse migration" and the labor might be in excess of the work needed to simply apply processing statuses to accessions by hand. Questions to evaluate the need include: a) How much work would be involved in creating "reverse migration"? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing status may not be that labor-intensive-it could be that not many accessions have been processed between migration and implementation. c) Did Archon have processing status? If so, were they also retained? d) How many repositories changed the default drop-downs for event records? Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Runyon, Carolyn Sent: Tuesday, February 16, 2016 4:18 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Chris, I'm going to answer two of the questions you posed in yesterday's email according to UTC's preference. * Yes, we would like to see processing event records migrated back to their original collection_management records and then removed. * Yes, we like to see processing tracked in collection_management only and have it removed as an option in events. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/bbd01959/attachment.html> From jvb at sfasu.edu Wed Feb 17 15:48:11 2016 From: jvb at sfasu.edu (Johna L Von Behrens) Date: Wed, 17 Feb 2016 20:48:11 +0000 Subject: [Archivesspace_Users_Group] Barcoding Message-ID: <A01F04C6A8ABA54CB3587082D1DEE0BC86895B45@EXCHMBOX01.sfasu.nac> Good afternoon group, We would like to keep track of collections that are being used. Is there an add-on or something (sorry not sure of the right language) that we can use in conjunction with AS's barcoding? We do have our library database but would like to keep it within AS. Thanks for any info. Johna Von Behrens, MLIS, CA, MSEd University<http://library.sfasu.edu/etrc/academic> Archivist and Records Manager East Texas Research Center<http://library.sfasu.edu/etrc/> Stephen F. Austin State University<http://www.sfasu.edu/> PO Box 13055 SFA Station Nacogdoches<http://www.ci.nacogdoches.tx.us/>, TX 75962 Phone 936.468.1536 Fax 936.468.7610 The views and opinions expressed in this message are my own and do not necessarily reflect the views and opinions of Stephen F. Austin State University, its Board of Regents, or the State of Texas. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/6091807e/attachment.html> From psuda1 at tulane.edu Wed Feb 17 16:31:01 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 17 Feb 2016 21:31:01 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Message-ID: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a "hidden" field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a 'plugin' to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/a4e8c484/attachment.html> From psuda1 at tulane.edu Wed Feb 17 16:33:00 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 17 Feb 2016 21:33:00 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BN1PR03MB266B77B386ACBB028A85FFFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> The repository table in the database that is....apologies. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a "hidden" field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a 'plugin' to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/d05e63bf/attachment.html> From maureen.callahan at yale.edu Wed Feb 17 16:39:29 2016 From: maureen.callahan at yale.edu (Callahan, Maureen) Date: Wed, 17 Feb 2016 21:39:29 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> Hey Phil, I don?t know if you?ve thought about using the API for updates like this, but we?re taking the approach of never touching the database directly (for safety reasons ? API updates help make sure that we?re only making changes that are schema-valid. Plus, those database table are hella complicated. Plus, API updates kick of re-indexing of that record automatically. Plus, I?m enjoying learning to use the API!). Here?s some extremely middling Python by someone who is very new at this to unpublish some resource records. This may inspire you to do something similar for your repository record: https://github.com/YaleArchivesSpace/ASpaceScripts/blob/master/UpdatePublish4Resource.py Thanks, Maureen On Feb 17, 2016, at 4:31 PM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a ?hidden? field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a ?plugin? to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=bsL4gXQLEorPl4XTlA_ZMzyTUER1c6GF9oZDhNfrP_U&s=KaIdnZKZqmhBTzg3zQJq7uSdK1jKJUxt-7NyjLWWg-0&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/ea358cb5/attachment.html> From psuda1 at tulane.edu Wed Feb 17 16:41:30 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 17 Feb 2016 21:41:30 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> Message-ID: <BN1PR03MB266216CCCD8164D7A3A263CE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Thanks Maureen, this is most helpful. I have been using my trusty SQL skills (and I backup everything like the dickens), but this seems better. I have been working with the API, just never thought to use it for this. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Callahan, Maureen Sent: Wednesday, February 17, 2016 3:39 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Hey Phil, I don?t know if you?ve thought about using the API for updates like this, but we?re taking the approach of never touching the database directly (for safety reasons ? API updates help make sure that we?re only making changes that are schema-valid. Plus, those database table are hella complicated. Plus, API updates kick of re-indexing of that record automatically. Plus, I?m enjoying learning to use the API!). Here?s some extremely middling Python by someone who is very new at this to unpublish some resource records. This may inspire you to do something similar for your repository record: https://github.com/YaleArchivesSpace/ASpaceScripts/blob/master/UpdatePublish4Resource.py Thanks, Maureen On Feb 17, 2016, at 4:31 PM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a ?hidden? field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a ?plugin? to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=bsL4gXQLEorPl4XTlA_ZMzyTUER1c6GF9oZDhNfrP_U&s=KaIdnZKZqmhBTzg3zQJq7uSdK1jKJUxt-7NyjLWWg-0&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/4930a266/attachment.html> From psuda1 at tulane.edu Wed Feb 17 16:42:48 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 17 Feb 2016 21:42:48 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <BN1PR03MB266216CCCD8164D7A3A263CE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> <BN1PR03MB266216CCCD8164D7A3A263CE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BN1PR03MB26649FEB6E0C00468624653E5AE0@BN1PR03MB266.namprd03.prod.outlook.com> I?ll share what I come up with. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Thanks Maureen, this is most helpful. I have been using my trusty SQL skills (and I backup everything like the dickens), but this seems better. I have been working with the API, just never thought to use it for this. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Callahan, Maureen Sent: Wednesday, February 17, 2016 3:39 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Hey Phil, I don?t know if you?ve thought about using the API for updates like this, but we?re taking the approach of never touching the database directly (for safety reasons ? API updates help make sure that we?re only making changes that are schema-valid. Plus, those database table are hella complicated. Plus, API updates kick of re-indexing of that record automatically. Plus, I?m enjoying learning to use the API!). Here?s some extremely middling Python by someone who is very new at this to unpublish some resource records. This may inspire you to do something similar for your repository record: https://github.com/YaleArchivesSpace/ASpaceScripts/blob/master/UpdatePublish4Resource.py Thanks, Maureen On Feb 17, 2016, at 4:31 PM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a ?hidden? field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a ?plugin? to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=bsL4gXQLEorPl4XTlA_ZMzyTUER1c6GF9oZDhNfrP_U&s=KaIdnZKZqmhBTzg3zQJq7uSdK1jKJUxt-7NyjLWWg-0&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/03376b36/attachment.html> From EJOLLEY at nla.gov.au Wed Feb 17 17:06:36 2016 From: EJOLLEY at nla.gov.au (Emma Jolley) Date: Wed, 17 Feb 2016 22:06:36 +0000 Subject: [Archivesspace_Users_Group] Collection management - processing status disappeared... In-Reply-To: <3975740D6A5FF946B2A77B95A7B228D7225C0226@xmail-mbx-bv1.AD.UCSD.EDU> References: <3975740D6A5FF946B2A77B95A7B228D720FAADF6@XMAIL-MBX-AV1.AD.UCSD.EDU> <CAHYOJB-uyAUYKio50FduR0D=NLj0aZ=76pHboo7xUm+ZnrpODQ@mail.gmail.com> <CO2PR0601MB742D57249269D12FE173C5BA5A90@CO2PR0601MB742.namprd06.prod.outlook.com> <61DF82E43FF6684FBA238273601C90A1593B2A64@ex10mb01.ad.uky.edu> <BY2PR08MB0634C180E10944D8FB69042FBAC0@BY2PR08MB063.namprd08.prod.outlook.com> <8D510ECA-63F3-475A-94A1-2B21BC7E2947@utc.edu> <SN1PR0701MB177557E8DCCE3102C026CAC080AE0@SN1PR0701MB1775.namprd07.prod.outlook.com> <3975740D6A5FF946B2A77B95A7B228D7225C0226@xmail-mbx-bv1.AD.UCSD.EDU> Message-ID: <81FF938BA2407B4DA1E134E7FA5C09EC02132C0486@EXMBX1.shire.nla.gov.au> Dear all Thanks for such a thorough discussion on this issue. We were very dismayed when the processing status field initially disappeared (not having been notified that this was going to happen in the first place). But when it did we adapted our workflows to use Events to track our various Accessioning and Processing stages and have done significant work to correct that problems associated with the movement of information from the Processing Status field to an Event. As such we agree with Kate's and Laurel's approach - we would not want to see the Events that we now use to track processing status disappear and would want to retain them. We are happy if the processing status is re-instated in Collection Management (we can always ignore the field if we don't want to use i) but would not want to see all of the information now in Events affected. Best wishes Emma National Library of Australia Emma Jolley| Curator of Digital Archives, Pictures and Manuscripts Branch|National Library of Australia Canberra ACT 2600 e: emma.jolley at nla.gov.au<mailto:emma.jolley at nla.gov.au>|t: 02 6262 1456| www.nla.gov.au/ms<http://www.nla.gov.au/ms> http://www.nla.gov.au/support-us/make-a-collection-offer-pictures-and-manuscripts From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Dougherty, Laurel Sent: Thursday, 18 February 2016 6:34 AM To: 'Archivesspace Users Group' Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I think Kate's approach sounds good. If the processing_status_id / cataloged fields and their related dates that are currently showing as Events can simply be made to reappear (populated with the data they contain) in the Collection Management subrecord (and Kate implies it's actually already there in the tables), then we're not necessarily proposing a sweeping deletion of folks' data or a change to the data model-just a restoration of functionality that has been the focus of this conversation. Perhaps this could happen in a sequence of events like this: 1) Following a pull request and prioritization/acceptance, a future version of ASpace is released with processing and cataloged status options (pull-down menus) and the other requisite fields that go along with them back in the Collection Management subrecord. Updating to this version doesn't cause anyone to lose data-it just reappears as it was originally migrated. 2) The migration tool is re-configured, for those who aren't in production yet, to have their AT processing status data mapped to the Collections Management subrecord 3) Institutions that want to wipe out their processing-related events can do so; if a plug-in is required to transfer data added to the Events module (post-migration), that is developed as a final step It's easy to configure the events by adding and deleting fields to fit your needs. So I wouldn't propose a reverse migration that wipes out processing events for everyone-after all, while re-reading Brad's post on this topic from November, this change was done with good intentions and was a deliberate extension of the PREMIS events model. I quote Brad here: "We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent." Some repositories may very well want to continue adding processing actions as events (i.e. "partially processed" by [agent] on [date]) to allow for granular reports on these types of events and agents in the future. But it seems, in addition, institutions simply want an option via Collection Management to say: is this stuff processed, or not? Because an event is not necessarily the same as a status. As others have pointed out, a status is just easier for querying and on-the-ground collection management. A one-time version change that exposes those relevant fields that were moved to Events and plops them back into the Collection Management subrecord might be a suitable minimum "do no harm" approach. Plug-ins to migrate data between the Events and Collections Management subrecords might be a slightly different issue. Respectfully, Laurel Laurel McPhee Dougherty Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | * 858-534-5619 | * l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Wednesday, February 17, 2016 8:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... I'm not sure that incorporating "reverse migration" for all into re-establishing the disappeared functionality would be wise. Rather a one-time "reversion helper" plug-in, that can be optionally executed by an ArchivesSpace repository, is better. Here's my thinking 1) Less work means more likelihood of getting the basic, vital functionality of "processing status" back into collection management records more quickly. By this I mean: the table is still there with the data in it (at least for AT migrations). Just put it back into the interface and for users and admins. 2) Status does not equal event. Status *may* be inferred from *some* events. 3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes. 4) Individual implementers may not need "reverse migration" and the labor might be in excess of the work needed to simply apply processing statuses to accessions by hand. Questions to evaluate the need include: a) How much work would be involved in creating "reverse migration"? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing status may not be that labor-intensive-it could be that not many accessions have been processed between migration and implementation. c) Did Archon have processing status? If so, were they also retained? d) How many repositories changed the default drop-downs for event records? Kate Kate Bowers Collections Services Archivist for Metadata, Systems, and Standards Harvard University Archives kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu> 617.496.2713 voice: (617) 384-7787 fax: (617) 495-8011 web: http://nrs.harvard.edu/urn-3:hul.eresource:archives Twitter: @k8_bowers From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Runyon, Carolyn Sent: Tuesday, February 16, 2016 4:18 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared... Chris, I'm going to answer two of the questions you posed in yesterday's email according to UTC's preference. * Yes, we would like to see processing event records migrated back to their original collection_management records and then removed. * Yes, we like to see processing tracked in collection_management only and have it removed as an option in events. Cheers, Carolyn Carolyn Runyon Assistant Head of Collection Services and Director of Special Collections University of Tennessee at Chattanooga Library 615 McCallie Ave., Chattanooga, TN 37403 Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503 Dept. 6456, LIB 439D On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/6d40c5f9/attachment.html> From PGalligan at rockarch.org Thu Feb 18 09:14:05 2016 From: PGalligan at rockarch.org (Galligan, Patrick) Date: Thu, 18 Feb 2016 09:14:05 -0500 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <BN1PR03MB26649FEB6E0C00468624653E5AE0@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> <BN1PR03MB266216CCCD8164D7A3A263CE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <BN1PR03MB26649FEB6E0C00468624653E5AE0@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <F6E0CB227A713F4AA8F9598060B8F063D8AD5001CB@racex01> Phil, We?ve been doing some work with publishing/unpublishing through the API as well. Hillel Arnold wrote a script that basically does the same thing that Maureen?s does if you?d like to take a look at it: https://github.com/RockefellerArchiveCenter/scripts/blob/master/archivesspace/asPublish.py In case anyone?s interested, we?ve also written a Python script to use the API to find and delete matching access restriction notes from archival objects across an entire repository. I?m sure it could be prettied up or expanded pretty easily, just submit a pull request: https://github.com/RockefellerArchiveCenter/as_notes_delete Patrick Galligan Rockefeller Archive Center Assistant Digital Archivist 914-366-6386 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 4:43 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface I?ll share what I come up with. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Thanks Maureen, this is most helpful. I have been using my trusty SQL skills (and I backup everything like the dickens), but this seems better. I have been working with the API, just never thought to use it for this. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Callahan, Maureen Sent: Wednesday, February 17, 2016 3:39 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Hey Phil, I don?t know if you?ve thought about using the API for updates like this, but we?re taking the approach of never touching the database directly (for safety reasons ? API updates help make sure that we?re only making changes that are schema-valid. Plus, those database table are hella complicated. Plus, API updates kick of re-indexing of that record automatically. Plus, I?m enjoying learning to use the API!). Here?s some extremely middling Python by someone who is very new at this to unpublish some resource records. This may inspire you to do something similar for your repository record: https://github.com/YaleArchivesSpace/ASpaceScripts/blob/master/UpdatePublish4Resource.py Thanks, Maureen On Feb 17, 2016, at 4:31 PM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a ?hidden? field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a ?plugin? to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=bsL4gXQLEorPl4XTlA_ZMzyTUER1c6GF9oZDhNfrP_U&s=KaIdnZKZqmhBTzg3zQJq7uSdK1jKJUxt-7NyjLWWg-0&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/88189c4f/attachment.html> From psuda1 at tulane.edu Thu Feb 18 09:36:49 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 18 Feb 2016 14:36:49 +0000 Subject: [Archivesspace_Users_Group] Unpublish Repository from Public Interface In-Reply-To: <F6E0CB227A713F4AA8F9598060B8F063D8AD5001CB@racex01> References: <BN1PR03MB266816B29D71E0F8354F2AFE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <6FABDE76-4E8F-40CC-AA0B-86D52B81039D@yale.edu> <BN1PR03MB266216CCCD8164D7A3A263CE5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <BN1PR03MB26649FEB6E0C00468624653E5AE0@BN1PR03MB266.namprd03.prod.outlook.com> <F6E0CB227A713F4AA8F9598060B8F063D8AD5001CB@racex01> Message-ID: <BN1PR03MB266E863777B1602462556D0E5AF0@BN1PR03MB266.namprd03.prod.outlook.com> Thanks Patrick. I appreciate this. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Galligan, Patrick Sent: Thursday, February 18, 2016 8:14 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Phil, We?ve been doing some work with publishing/unpublishing through the API as well. Hillel Arnold wrote a script that basically does the same thing that Maureen?s does if you?d like to take a look at it: https://github.com/RockefellerArchiveCenter/scripts/blob/master/archivesspace/asPublish.py In case anyone?s interested, we?ve also written a Python script to use the API to find and delete matching access restriction notes from archival objects across an entire repository. I?m sure it could be prettied up or expanded pretty easily, just submit a pull request: https://github.com/RockefellerArchiveCenter/as_notes_delete Patrick Galligan Rockefeller Archive Center Assistant Digital Archivist 914-366-6386 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 4:43 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface I?ll share what I come up with. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 17, 2016 3:42 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Thanks Maureen, this is most helpful. I have been using my trusty SQL skills (and I backup everything like the dickens), but this seems better. I have been working with the API, just never thought to use it for this. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Callahan, Maureen Sent: Wednesday, February 17, 2016 3:39 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Unpublish Repository from Public Interface Hey Phil, I don?t know if you?ve thought about using the API for updates like this, but we?re taking the approach of never touching the database directly (for safety reasons ? API updates help make sure that we?re only making changes that are schema-valid. Plus, those database table are hella complicated. Plus, API updates kick of re-indexing of that record automatically. Plus, I?m enjoying learning to use the API!). Here?s some extremely middling Python by someone who is very new at this to unpublish some resource records. This may inspire you to do something similar for your repository record: https://github.com/YaleArchivesSpace/ASpaceScripts/blob/master/UpdatePublish4Resource.py Thanks, Maureen On Feb 17, 2016, at 4:31 PM, Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> wrote: Greetings all, I figured out how to unpublish the repository. In the repository table in the table, there is a ?hidden? field. Changing this from 0 to 1 hides the repository. You will have to stop/start/reindex your instance. Thanks, Phil From: Suda, Phillip J Sent: Monday, February 15, 2016 12:26 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Unpublish Repository from Public Interface Greetings all, A library (repository) wants to unpublish all of their records. I have figured out how to do this on the sql/database side of things. Is there a way to unpublish/suppress a repository from the repository tab? Or do I need to use some javascript to hide the repository in question? I tried finding the page in the view to create a ?plugin? to only list certain repositories, but I cannot find the view in question. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=bsL4gXQLEorPl4XTlA_ZMzyTUER1c6GF9oZDhNfrP_U&s=KaIdnZKZqmhBTzg3zQJq7uSdK1jKJUxt-7NyjLWWg-0&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/7b3a3103/attachment.html> From Joshua.D.Shaw at dartmouth.edu Thu Feb 18 10:35:07 2016 From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw) Date: Thu, 18 Feb 2016 15:35:07 +0000 Subject: [Archivesspace_Users_Group] Hide an AppConfig value in the System Info Report Message-ID: <0ABAD0D3-77A9-4632-BA9A-D4E46C4761D5@dartmouth.edu> Hey all- I was poking around to try and find an answer for one problem and ran into another issue - of course! Anyway, we have a plugin that needs a username and password for a third party service set in the config file - at least that's the way we had it developed. Is there a way to have an AppConfig setting in the config file, but tell the application itself to not display the value in the system_info report? The system_info report already blocks the db password, so I'm hoping there's an additional flag I can set to do the same for this particular setting. If not, I'll see what I can do about obfuscating the password in some other fashion. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/a9782e66/attachment.html> From ltang5 at mail.lib.msu.edu Thu Feb 18 14:13:46 2016 From: ltang5 at mail.lib.msu.edu (Tang, Lydia) Date: Thu, 18 Feb 2016 19:13:46 +0000 Subject: [Archivesspace_Users_Group] Container Management plug-in and 1.5 update question Message-ID: <54586933-9E46-4AD0-9EDF-FE4EED1575EE@mail.lib.msu.edu> Hello! I just wanted to check on the timeline for the ArchivesSpace 1.5 version to come out? I recently came across Yale?s cool container management plug-in, which sounds like it would be really helpful for my situation, since we will be sending the majority of our collections to a remote storage while our space is renovated. http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement Container Management on GitHub https://github.com/hudmol/container_management Apparently it?s not compatible with the version of Aspace we?re currently running (1.4) and I read that the plug-in will be incorporated into the main code for the 1.5 update, and just wanted to check on its timeline. Thanks! Lydia From dsimmons at siu.edu Thu Feb 18 14:36:04 2016 From: dsimmons at siu.edu (Douglas James Simmons) Date: Thu, 18 Feb 2016 19:36:04 +0000 Subject: [Archivesspace_Users_Group] re-indexing errors for a 1.3.0 instance Message-ID: <CO1PR07MB393DEACD099483A47AB4672C3AF0@CO1PR07MB393.namprd07.prod.outlook.com> I was asked to move all accessions data from one repository to another one. It seemed from looking at the tables like a simple sql update. In each accessions record in mysql, I replaced the old repo_id with the new one. I stopped the archivesspace server, deleted /data/solr_index/index and restarted it. The solr console reported : [collection1] Solr index directory '/home/ambika/Documents/Feb130/archivesspace/data/solr_index/index' doesn't exist. Creating new index... As expected. However, it now shows multiple entries like: 13:28:36 SEVERE SolrCore java.lang.NullPointerException 13:28:36 SEVERE SolrDispatchFilter null:java.lang.NullPointerException Should I restore the db from backup and try doing this a different way? Would this process involve the resequencing flag to be set at startup? Thanks, DOUG SIMMONS Assistant Manager MORRIS LIBRARY - SYSTEMS MAIL CODE 6632 SOUTHERN ILLINOIS UNIVERSITY 605 AGRICULTURE DRIVE CARBONDALE, ILLINOIS? 62901 dsimmons at siu.edu P: 618/453-1026 F: 618/453-3440 LIB.SIU.EDU From brianjhoffman at gmail.com Thu Feb 18 14:58:57 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Thu, 18 Feb 2016 14:58:57 -0500 Subject: [Archivesspace_Users_Group] re-indexing errors for a 1.3.0 instance In-Reply-To: <CO1PR07MB393DEACD099483A47AB4672C3AF0@CO1PR07MB393.namprd07.prod.outlook.com> References: <CO1PR07MB393DEACD099483A47AB4672C3AF0@CO1PR07MB393.namprd07.prod.outlook.com> Message-ID: <C2273859-FCA2-40EE-BBC1-FD8F3AFB6393@gmail.com> Hi, Yes, you should definitely restore from your backup and then look into doing this through the UI or the API. Transferring top-level records via SQL is very likely going to result in corrupted data that you will have a difficult time remediating down the road. Brian > On Feb 18, 2016, at 2:36 PM, Douglas James Simmons <dsimmons at siu.edu> wrote: > > I was asked to move all accessions data from one repository to another one. It seemed from looking at the tables like a simple sql update. > > In each accessions record in mysql, I replaced the old repo_id with the new one. > I stopped the archivesspace server, deleted /data/solr_index/index and restarted it. The solr console reported : > > [collection1] Solr index directory '/home/ambika/Documents/Feb130/archivesspace/data/solr_index/index' doesn't exist. Creating new index... > > As expected. However, it now shows multiple entries like: > > 13:28:36 SEVERE SolrCore java.lang.NullPointerException > 13:28:36 SEVERE SolrDispatchFilter null:java.lang.NullPointerException > > Should I restore the db from backup and try doing this a different way? Would this process involve the resequencing flag to be set at startup? > > Thanks, > > DOUG SIMMONS > Assistant Manager > > MORRIS LIBRARY - SYSTEMS > MAIL CODE 6632 > SOUTHERN ILLINOIS UNIVERSITY > 605 AGRICULTURE DRIVE > CARBONDALE, ILLINOIS 62901 > > dsimmons at siu.edu > P: 618/453-1026 > F: 618/453-3440 > LIB.SIU.EDU > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From Joshua.D.Shaw at dartmouth.edu Thu Feb 18 15:42:17 2016 From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw) Date: Thu, 18 Feb 2016 20:42:17 +0000 Subject: [Archivesspace_Users_Group] Container Management plug-in and 1.5 update question In-Reply-To: <54586933-9E46-4AD0-9EDF-FE4EED1575EE@mail.lib.msu.edu> References: <54586933-9E46-4AD0-9EDF-FE4EED1575EE@mail.lib.msu.edu> Message-ID: <85FE0B14-BBA8-4F09-851A-7A9AE2554DE0@dartmouth.edu> Hi Lydia- The version from HM is 1.4.1+ compatible as of the last commit to the repo in case you want to start in with this sooner. Its release 1.1 FYI - Dartmouth uses a somewhat customized version, though we are still running against 1.3.0. Joshua On 2/18/16, 2:13 PM, "Tang, Lydia" <ltang5 at mail.lib.msu.edu> wrote: >Hello! >I just wanted to check on the timeline for the ArchivesSpace 1.5 version >to come out? I recently came across Yale?s cool container management >plug-in, which sounds like it would be really helpful for my situation, >since we will be sending the majority of our collections to a remote >storage while our space is renovated. >http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement >Container Management on GitHub >https://github.com/hudmol/container_management >Apparently it?s not compatible with the version of Aspace we?re currently >running (1.4) and I read that the plug-in will be incorporated into the >main code for the 1.5 update, and just wanted to check on its timeline. >Thanks! >Lydia > >_______________________________________________ >Archivesspace_Users_Group mailing list >Archivesspace_Users_Group at lyralists.lyrasis.org >http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From longh at uncw.edu Thu Feb 18 16:21:18 2016 From: longh at uncw.edu (Long, Holley W.) Date: Thu, 18 Feb 2016 21:21:18 +0000 Subject: [Archivesspace_Users_Group] Transfer failed Message-ID: <BY2PR06MB175188DCC0ECA09922DC8016CDAF0@BY2PR06MB1751.namprd06.prod.outlook.com> Hello All, My library is migrating one repository in Archon to two repositories in ArchivesSpace. Our plan is to move the Archon repository into ArchivesSpace and then transfer collections to the second repository using ArchivesSpace's transfer functionality. I just tried this out in our test instance and got the following error message. I get the same error regardless of whether the collection has linked agents or not. Has anyone encountered this error or have an idea why it is occurring? Thanks in advance for your help- Regards, Holley Long Transfer Failed: {"error":{"linked_agents/0/ref":["Must be one of: JSONModel(:agent_corporate_entity) uri, JSONModel(:agent_family) uri, JSONModel(:agent_person) uri, JSONModel(:agent_software) uri (you provided a String)"]},"warning":null,"invalid_object":"#<JSONModel(:event) {\"linked_agents\"=>[{\"role\"=>\"transmitter\", \"ref\"=>\"/agents/corporate_entities\"}, {\"role\"=>\"recipient\", \"ref\"=>\"/agents/corporate_entities/298\"}], \"linked_records\"=>[{\"role\"=>\"transfer\", \"ref\"=>\"/repositories/3/resources/609\"}], \"event_type\"=>\"custody_transfer\", \"timestamp\"=>\"2016-02-18T20:58:54Z\", \"jsonmodel_type\"=>\"event\", \"external_ids\"=>[], \"external_documents\"=>[]}>"} Holley Long Digital Initiatives Librarian Randall Library, University of North Carolina Wilmington longh at uncw.edu<mailto:longh at uncw.edu> 910-962-7592 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/dfcc6485/attachment.html> From brianjhoffman at gmail.com Thu Feb 18 16:43:17 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Thu, 18 Feb 2016 16:43:17 -0500 Subject: [Archivesspace_Users_Group] Transfer failed In-Reply-To: <BY2PR06MB175188DCC0ECA09922DC8016CDAF0@BY2PR06MB1751.namprd06.prod.outlook.com> References: <BY2PR06MB175188DCC0ECA09922DC8016CDAF0@BY2PR06MB1751.namprd06.prod.outlook.com> Message-ID: <DC9AF624-E4CF-481B-826E-A7975A7F4451@gmail.com> Hi Holley, What do you see if you navigate to: agents/agent_corporate_entity/298 ? Also, what version of ArchivesSpace are you using? Brian > On Feb 18, 2016, at 4:21 PM, Long, Holley W. <longh at uncw.edu> wrote: > > Hello All, > > My library is migrating one repository in Archon to two repositories in ArchivesSpace. Our plan is to move the Archon repository into ArchivesSpace and then transfer collections to the second repository using ArchivesSpace?s transfer functionality. I just tried this out in our test instance and got the following error message. I get the same error regardless of whether the collection has linked agents or not. Has anyone encountered this error or have an idea why it is occurring? > > Thanks in advance for your help? > > Regards, > Holley Long > > Transfer Failed: {"error":{"linked_agents/0/ref":["Must be one of: JSONModel(:agent_corporate_entity) uri, JSONModel(:agent_family) uri, JSONModel(:agent_person) uri, JSONModel(:agent_software) uri (you provided a String)"]},"warning":null,"invalid_object":"#<JSONModel(:event) {\"linked_agents\"=>[{\"role\"=>\"transmitter\", \"ref\"=>\"/agents/corporate_entities\"}, {\"role\"=>\"recipient\", \"ref\"=>\"/agents/corporate_entities/298\"}], \"linked_records\"=>[{\"role\"=>\"transfer\", \"ref\"=>\"/repositories/3/resources/609\"}], \"event_type\"=>\"custody_transfer\", \"timestamp\"=>\"2016-02-18T20:58:54Z\", \"jsonmodel_type\"=>\"event\", \"external_ids\"=>[], \"external_documents\"=>[]}>"} > > > Holley Long > Digital Initiatives Librarian > Randall Library, University of North Carolina Wilmington > longh at uncw.edu <mailto:longh at uncw.edu> > 910-962-7592 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/ed77361d/attachment.html> From Diana.Gunnells at unco.edu Thu Feb 18 18:06:13 2016 From: Diana.Gunnells at unco.edu (Gunnells, Diana) Date: Thu, 18 Feb 2016 23:06:13 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Message-ID: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> Has anyone been able to spawn an Accession Record to Resource Record lately? The function has worked in the past but has been reported to me that staff are now seeing the following message: NoMethodError in ResourcesController#new undefined method `editable?' for ["abstract", "langmaterial"]:Array It appears to only be a problem with resource records. Spawning a new Accession record works as expected. Thoughts/advice? Thanks so much! Diana Diana Gunnells University Libraries Library Applications [cid:image003.png at 01D16A66.49CEC0B0] University of Northern Colorado Michener Library 121 Campus Box 48 Greeley, CO 80639 O: 970-351-2564 diana.gunnells at unco.edu<mailto:diana.gunnells at unco.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/85962972/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 19400 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/85962972/attachment.png> From brad.westbrook at lyrasis.org Thu Feb 18 18:40:56 2016 From: brad.westbrook at lyrasis.org (Brad Westbrook) Date: Thu, 18 Feb 2016 23:40:56 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> Message-ID: <BN1PR08MB011E1D61DB755E107E265BD94AF0@BN1PR08MB011.namprd08.prod.outlook.com> Hi, Diana, What version of ArchivesSpace are you using? I am not able to replicate this problem in v1.4.2. Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Thursday, February 18, 2016 6:06 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Has anyone been able to spawn an Accession Record to Resource Record lately? The function has worked in the past but has been reported to me that staff are now seeing the following message: NoMethodError in ResourcesController#new undefined method `editable?' for ["abstract", "langmaterial"]:Array It appears to only be a problem with resource records. Spawning a new Accession record works as expected. Thoughts/advice? Thanks so much! Diana Diana Gunnells University Libraries Library Applications [cid:image001.png at 01D16A7C.29378B50] University of Northern Colorado Michener Library 121 Campus Box 48 Greeley, CO 80639 O: 970-351-2564 diana.gunnells at unco.edu<mailto:diana.gunnells at unco.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/428ebc54/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19400 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160218/428ebc54/attachment.png> From brad.westbrook at lyrasis.org Fri Feb 19 07:13:14 2016 From: brad.westbrook at lyrasis.org (Brad Westbrook) Date: Fri, 19 Feb 2016 12:13:14 +0000 Subject: [Archivesspace_Users_Group] Container Management plug-in and 1.5 update question In-Reply-To: <54586933-9E46-4AD0-9EDF-FE4EED1575EE@mail.lib.msu.edu> References: <54586933-9E46-4AD0-9EDF-FE4EED1575EE@mail.lib.msu.edu> Message-ID: <BN1PR08MB011E6A62E8B5AA939EF0FEE94A00@BN1PR08MB011.namprd08.prod.outlook.com> Good morning, Lydia, We are targeting the end of April for distributing the v1.5 release of ArchivesSpace. Please bear in mind that the actual release date is dependent on implementing all the essential features of the container management plugin. Brad W. -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Thursday, February 18, 2016 2:14 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Container Management plug-in and 1.5 update question Hello! I just wanted to check on the timeline for the ArchivesSpace 1.5 version to come out? I recently came across Yale?s cool container management plug-in, which sounds like it would be really helpful for my situation, since we will be sending the majority of our collections to a remote storage while our space is renovated. http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement Container Management on GitHub https://github.com/hudmol/container_management Apparently it?s not compatible with the version of Aspace we?re currently running (1.4) and I read that the plug-in will be incorporated into the main code for the 1.5 update, and just wanted to check on its timeline. Thanks! Lydia _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From Diana.Gunnells at unco.edu Fri Feb 19 09:17:38 2016 From: Diana.Gunnells at unco.edu (Gunnells, Diana) Date: Fri, 19 Feb 2016 14:17:38 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <BN1PR08MB011E1D61DB755E107E265BD94AF0@BN1PR08MB011.namprd08.prod.outlook.com> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> <BN1PR08MB011E1D61DB755E107E265BD94AF0@BN1PR08MB011.namprd08.prod.outlook.com> Message-ID: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFF4C4@ITEXDB04.unco.edu> Brad, We are still on v.1.4.1. Looks like we need to upgrade. Is v1.4.2 in general release? Diana Gunnells University Libraries Library Applications UNC | University of Northern Colorado Michener Library 121 | Campus Box 48 | Greeley, CO 80639 O: 970-351-2564 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Thursday, February 18, 2016 4:41 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Hi, Diana, What version of ArchivesSpace are you using? I am not able to replicate this problem in v1.4.2. Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Thursday, February 18, 2016 6:06 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Has anyone been able to spawn an Accession Record to Resource Record lately? The function has worked in the past but has been reported to me that staff are now seeing the following message: NoMethodError in ResourcesController#new undefined method `editable?' for ["abstract", "langmaterial"]:Array It appears to only be a problem with resource records. Spawning a new Accession record works as expected. Thoughts/advice? Thanks so much! Diana Diana Gunnells University Libraries Library Applications [cid:image001.png at 01D16AE5.6E3AB010] University of Northern Colorado Michener Library 121 Campus Box 48 Greeley, CO 80639 O: 970-351-2564 diana.gunnells at unco.edu<mailto:diana.gunnells at unco.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/468df2cd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19400 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/468df2cd/attachment.png> From brad.westbrook at lyrasis.org Fri Feb 19 09:20:03 2016 From: brad.westbrook at lyrasis.org (Brad Westbrook) Date: Fri, 19 Feb 2016 14:20:03 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFF4C4@ITEXDB04.unco.edu> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> <BN1PR08MB011E1D61DB755E107E265BD94AF0@BN1PR08MB011.namprd08.prod.outlook.com> <5E168CC28D85D74FBDFA1BC5CA02E79D31BFF4C4@ITEXDB04.unco.edu> Message-ID: <BN1PR08MB0111B4B814053E778834B2094A00@BN1PR08MB011.namprd08.prod.outlook.com> Hi, Diana, V1.4.2 is the current public release. You can download it from https://github.com/archivesspace/archivesspace/releases/tag/v1.4.2. Brad From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Friday, February 19, 2016 9:18 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Brad, We are still on v.1.4.1. Looks like we need to upgrade. Is v1.4.2 in general release? Diana Gunnells University Libraries Library Applications UNC | University of Northern Colorado Michener Library 121 | Campus Box 48 | Greeley, CO 80639 O: 970-351-2564 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Thursday, February 18, 2016 4:41 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Hi, Diana, What version of ArchivesSpace are you using? I am not able to replicate this problem in v1.4.2. Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Thursday, February 18, 2016 6:06 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Has anyone been able to spawn an Accession Record to Resource Record lately? The function has worked in the past but has been reported to me that staff are now seeing the following message: NoMethodError in ResourcesController#new undefined method `editable?' for ["abstract", "langmaterial"]:Array It appears to only be a problem with resource records. Spawning a new Accession record works as expected. Thoughts/advice? Thanks so much! Diana Diana Gunnells University Libraries Library Applications [cid:image001.png at 01D16AF6.F948EC60] University of Northern Colorado Michener Library 121 Campus Box 48 Greeley, CO 80639 O: 970-351-2564 diana.gunnells at unco.edu<mailto:diana.gunnells at unco.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/8a29a1bd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19400 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/8a29a1bd/attachment.png> From ltang5 at mail.lib.msu.edu Fri Feb 19 09:37:07 2016 From: ltang5 at mail.lib.msu.edu (Tang, Lydia) Date: Fri, 19 Feb 2016 14:37:07 +0000 Subject: [Archivesspace_Users_Group] buggy "Range" in RDE Message-ID: <92285C05-BFCB-4DBE-A24D-C6B117500A8E@mail.lib.msu.edu> Good morning! In the Rapid Data Entry drop down lists for Date Type, we have ?Range? as well as "Inclusive." Besides sometimes being a little confused about when it would be best to use one over the other, I realized that Range is not included in the conventional entry date drop-down at all, and when I revisit RDE objects with Range, the Date Expression was automatically changed to ?other? from our default ?creation.? It sounds like Range would like to be phased out completely (if going off of the conventional entry), which would streamline and clean up data. If so, could the RDE Range drop-down option just be killed, to avoid confusion? Thanks for your help! Lydia From Diana.Gunnells at unco.edu Fri Feb 19 09:56:55 2016 From: Diana.Gunnells at unco.edu (Gunnells, Diana) Date: Fri, 19 Feb 2016 14:56:55 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <BN1PR08MB0111B4B814053E778834B2094A00@BN1PR08MB011.namprd08.prod.outlook.com> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> <BN1PR08MB011E1D61DB755E107E265BD94AF0@BN1PR08MB011.namprd08.prod.outlook.com> <5E168CC28D85D74FBDFA1BC5CA02E79D31BFF4C4@ITEXDB04.unco.edu> <BN1PR08MB0111B4B814053E778834B2094A00@BN1PR08MB011.namprd08.prod.outlook.com> Message-ID: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFF6D4@ITEXDB04.unco.edu> Thanks Brad, I will send the information along to those that update our software. Diana Gunnells University Libraries Library Applications UNC | University of Northern Colorado Michener Library 121 | Campus Box 48 | Greeley, CO 80639 O: 970-351-2564 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Friday, February 19, 2016 7:20 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Hi, Diana, V1.4.2 is the current public release. You can download it from https://github.com/archivesspace/archivesspace/releases/tag/v1.4.2. Brad From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Friday, February 19, 2016 9:18 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Brad, We are still on v.1.4.1. Looks like we need to upgrade. Is v1.4.2 in general release? Diana Gunnells University Libraries Library Applications UNC | University of Northern Colorado Michener Library 121 | Campus Box 48 | Greeley, CO 80639 O: 970-351-2564 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Brad Westbrook Sent: Thursday, February 18, 2016 4:41 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Hi, Diana, What version of ArchivesSpace are you using? I am not able to replicate this problem in v1.4.2. Brad W. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gunnells, Diana Sent: Thursday, February 18, 2016 6:06 PM To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Has anyone been able to spawn an Accession Record to Resource Record lately? The function has worked in the past but has been reported to me that staff are now seeing the following message: NoMethodError in ResourcesController#new undefined method `editable?' for ["abstract", "langmaterial"]:Array It appears to only be a problem with resource records. Spawning a new Accession record works as expected. Thoughts/advice? Thanks so much! Diana Diana Gunnells University Libraries Library Applications [cid:image001.png at 01D16AEB.17770570] University of Northern Colorado Michener Library 121 Campus Box 48 Greeley, CO 80639 O: 970-351-2564 diana.gunnells at unco.edu<mailto:diana.gunnells at unco.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b423fcf6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19400 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b423fcf6/attachment.png> From christine.dibella at lyrasis.org Fri Feb 19 09:52:44 2016 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Fri, 19 Feb 2016 14:52:44 +0000 Subject: [Archivesspace_Users_Group] buggy "Range" in RDE In-Reply-To: <92285C05-BFCB-4DBE-A24D-C6B117500A8E@mail.lib.msu.edu> References: <92285C05-BFCB-4DBE-A24D-C6B117500A8E@mail.lib.msu.edu> Message-ID: <SN1PR08MB1967CBE9F02E9A11C5E5DB87F1A00@SN1PR08MB1967.namprd08.prod.outlook.com> Hi Lydia, Thanks for pointing this out. This bug was previously reported (see https://archivesspace.atlassian.net/browse/AR-1333) and is fixed for the next release. In the interim, you'll definitely want to advise your users to avoid selecting "Range" when creating dates in the RDE. Christine Christine Di Bella ArchivesSpace Community Outreach and Support Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype)? -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Friday, February 19, 2016 9:37 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] buggy "Range" in RDE Good morning! In the Rapid Data Entry drop down lists for Date Type, we have ?Range? as well as "Inclusive." Besides sometimes being a little confused about when it would be best to use one over the other, I realized that Range is not included in the conventional entry date drop-down at all, and when I revisit RDE objects with Range, the Date Expression was automatically changed to ?other? from our default ?creation.? It sounds like Range would like to be phased out completely (if going off of the conventional entry), which would streamline and clean up data. If so, could the RDE Range drop-down option just be killed, to avoid confusion? Thanks for your help! Lydia _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From longh at uncw.edu Fri Feb 19 10:09:38 2016 From: longh at uncw.edu (Long, Holley W.) Date: Fri, 19 Feb 2016 15:09:38 +0000 Subject: [Archivesspace_Users_Group] FW: Transfer failed In-Reply-To: <04191e23219b4ec198d6fed7fef1ba6b@CY1PR0601MB1099.namprd06.prod.outlook.com> References: <BY2PR06MB175188DCC0ECA09922DC8016CDAF0@BY2PR06MB1751.namprd06.prod.outlook.com>, <DC9AF624-E4CF-481B-826E-A7975A7F4451@gmail.com> <04191e23219b4ec198d6fed7fef1ba6b@CY1PR0601MB1099.namprd06.prod.outlook.com> Message-ID: <BY2PR06MB17513B04F810AEE9E4E2BA55CDA00@BY2PR06MB1751.namprd06.prod.outlook.com> Hi Brian, I've attached a screenshot so you can see what I see... It is a corporate agent record, called test repository, with nothing linked to it. "Test repository" is the name of the repository that I created to test the functionality. We are running v1.4.0. Thanks for your help, Brian. Regards, Holley From: Fleming, Jason Sent: Thursday, February 18, 2016 4:43 PM To: Long, Holley W. <longh at uncw.edu> Subject: FW: [Archivesspace_Users_Group] Transfer failed ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.orgOn<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.orgOn> Behalf OfBrian Hoffman Sent: Thursday, February 18, 2016 4:43:17 PM (UTC-05:00) Eastern Time (US & Canada) To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Transfer failed Hi Holley, What do you see if you navigate to: agents/agent_corporate_entity/298 ? Also, what version of ArchivesSpace are you using? Brian On Feb 18, 2016, at 4:21 PM, Long, Holley W. <longh at uncw.edu<mailto:longh at uncw.edu>> wrote: Hello All, My library is migrating one repository in Archon to two repositories in ArchivesSpace. Our plan is to move the Archon repository into ArchivesSpace and then transfer collections to the second repository using ArchivesSpace's transfer functionality. I just tried this out in our test instance and got the following error message. I get the same error regardless of whether the collection has linked agents or not. Has anyone encountered this error or have an idea why it is occurring? Thanks in advance for your help- Regards, Holley Long Transfer Failed: {"error":{"linked_agents/0/ref":["Must be one of: JSONModel(:agent_corporate_entity) uri, JSONModel(:agent_family) uri, JSONModel(:agent_person) uri, JSONModel(:agent_software) uri (you provided a String)"]},"warning":null,"invalid_object":"#<JSONModel(:event) {\"linked_agents\"=>[{\"role\"=>\"transmitter\", \"ref\"=>\"/agents/corporate_entities\"}, {\"role\"=>\"recipient\", \"ref\"=>\"/agents/corporate_entities/298\"}], \"linked_records\"=>[{\"role\"=>\"transfer\", \"ref\"=>\"/repositories/3/resources/609\"}], \"event_type\"=>\"custody_transfer\", \"timestamp\"=>\"2016-02-18T20:58:54Z\", \"jsonmodel_type\"=>\"event\", \"external_ids\"=>[], \"external_documents\"=>[]}>"} Holley Long Digital Initiatives Librarian Randall Library, University of North Carolina Wilmington longh at uncw.edu<mailto:longh at uncw.edu> 910-962-7592 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/fba1a48f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: agentSS.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 3321665 bytes Desc: agentSS.docx URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/fba1a48f/attachment.docx> From ljdavis at jhu.edu Fri Feb 19 09:47:59 2016 From: ljdavis at jhu.edu (Lora Davis) Date: Fri, 19 Feb 2016 14:47:59 +0000 Subject: [Archivesspace_Users_Group] buggy "Range" in RDE In-Reply-To: <92285C05-BFCB-4DBE-A24D-C6B117500A8E@mail.lib.msu.edu> References: <92285C05-BFCB-4DBE-A24D-C6B117500A8E@mail.lib.msu.edu> Message-ID: <1b833d4b29e44a83baf10f62800b14b3@ESGEBEX8.win.ad.jhu.edu> Hi Lydia, This seems related to a ticket I submitted a few months ago while at Colgate; see https://archivesspace.atlassian.net/browse/AR-1333. What version are you running? The problem has been fixed, but only as of 1.4.3-dev17 according to JIRA. And, yes, "Range" is intended only to be used in certain specific scenarios (e.g. in agent records), but not when describing materials. This was corrected a few releases ago, and "Range" removed from non-RDE fields, but it clung on in RDE causing the issue you encountered. Best, Lora -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Friday, February 19, 2016 9:37 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] buggy "Range" in RDE Good morning! In the Rapid Data Entry drop down lists for Date Type, we have ?Range? as well as "Inclusive." Besides sometimes being a little confused about when it would be best to use one over the other, I realized that Range is not included in the conventional entry date drop-down at all, and when I revisit RDE objects with Range, the Date Expression was automatically changed to ?other? from our default ?creation.? It sounds like Range would like to be phased out completely (if going off of the conventional entry), which would streamline and clean up data. If so, could the RDE Range drop-down option just be killed, to avoid confusion? Thanks for your help! Lydia _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From akroeger at unomaha.edu Fri Feb 19 10:57:52 2016 From: akroeger at unomaha.edu (Angela Kroeger) Date: Fri, 19 Feb 2016 15:57:52 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> Message-ID: <DM2PR07MB97380227C8F5E9569E084C1D3A00@DM2PR07MB973.namprd07.prod.outlook.com> Diana, I was able to spawn a Resource Record from an Accession Record this morning. I did not get the error you reported. We are on release 1.4.2. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/93f592da/attachment.html> From jrobertson at monticello.org Fri Feb 19 11:08:06 2016 From: jrobertson at monticello.org (Jack Robertson) Date: Fri, 19 Feb 2016 16:08:06 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Message-ID: <C220C0988576FC458F8B6CFD27832A2020C3F2C2@GRANGER.monticello.org> Dear Everyone, We at Monticello are new members of A-Space and I have been following the conversations on the lyralists Users Group with awe and admiration. The technical issues are complex and your expertise is impressive! We have been using Archon for the past four years, and are eager to migrate to A-Space. I write now to ask if I can be referred to publicly-accessible instances of A-Space? We've found and checked out the Sandbox, and now we are hoping to see how archives have made finding aids available to the public. Thanks very much, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/d8be024b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 5303 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/d8be024b/attachment.jpg> From Diana.Gunnells at unco.edu Fri Feb 19 11:13:52 2016 From: Diana.Gunnells at unco.edu (Gunnells, Diana) Date: Fri, 19 Feb 2016 16:13:52 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to Resource record not working In-Reply-To: <DM2PR07MB97380227C8F5E9569E084C1D3A00@DM2PR07MB973.namprd07.prod.outlook.com> References: <5E168CC28D85D74FBDFA1BC5CA02E79D31BFDD17@ITEXDB04.unco.edu> <DM2PR07MB97380227C8F5E9569E084C1D3A00@DM2PR07MB973.namprd07.prod.outlook.com> Message-ID: <5E168CC28D85D74FBDFA1BC5CA02E79D31C00003@ITEXDB04.unco.edu> Thanks Angela, That's what I have been hearing. I just found out this morning that we have not upgraded to 1.4.2 so I have put in a request to those that control our server. :) Thanks again! Diana Gunnells University Libraries Library Applications UNC | University of Northern Colorado Michener Library 121 | Campus Box 48 | Greeley, CO 80639 O: 970-351-2564 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Angela Kroeger Sent: Friday, February 19, 2016 8:58 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to Resource record not working Diana, I was able to spawn a Resource Record from an Accession Record this morning. I did not get the error you reported. We are on release 1.4.2. Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/e85e87fd/attachment.html> From smithkr at mit.edu Fri Feb 19 11:21:16 2016 From: smithkr at mit.edu (Kari R Smith) Date: Fri, 19 Feb 2016 16:21:16 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet In-Reply-To: <C220C0988576FC458F8B6CFD27832A2020C3F2C2@GRANGER.monticello.org> References: <C220C0988576FC458F8B6CFD27832A2020C3F2C2@GRANGER.monticello.org> Message-ID: <29F559819ACA9A4FBF208407D4B63ABBD74A5F8D@OC11EXPO32.exchange.mit.edu> Hi Jack and Welcome to the community! When you look at the ArchivesSpace Members webpage ... any name that is blue is live linked and goes to that organization's ArchivesSpace instance. http://www.archivesspace.org/members We hope that you'll consider joining the ArchivesSpace community through contributing to the listserv with both questions and answers as you're more familiar with the tool. Kari Smith MIT Institute Archives and Special Collecitons From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jack Robertson Sent: Friday, February 19, 2016 11:08 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Dear Everyone, We at Monticello are new members of A-Space and I have been following the conversations on the lyralists Users Group with awe and admiration. The technical issues are complex and your expertise is impressive! We have been using Archon for the past four years, and are eager to migrate to A-Space. I write now to ask if I can be referred to publicly-accessible instances of A-Space? We've found and checked out the Sandbox, and now we are hoping to see how archives have made finding aids available to the public. Thanks very much, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/8389b49b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 5303 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/8389b49b/attachment.jpg> From jrobertson at monticello.org Fri Feb 19 11:29:18 2016 From: jrobertson at monticello.org (Jack Robertson) Date: Fri, 19 Feb 2016 16:29:18 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet In-Reply-To: <29F559819ACA9A4FBF208407D4B63ABBD74A5F8D@OC11EXPO32.exchange.mit.edu> References: <C220C0988576FC458F8B6CFD27832A2020C3F2C2@GRANGER.monticello.org> <29F559819ACA9A4FBF208407D4B63ABBD74A5F8D@OC11EXPO32.exchange.mit.edu> Message-ID: <C220C0988576FC458F8B6CFD27832A2020C3F324@GRANGER.monticello.org> Dear Kari, OK, many thanks. I'll take a close look at the blued names. I do have another "raw beginner's" question: I am contemplating going to the SAA conference in Atlanta, and I wonder how much and what types of A-Space meetings/discussions I might anticipate encountering? Do you recommend SAA as a good venue for a novice A-Spacer? Cheers, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library From: Kari R Smith [mailto:smithkr at mit.edu] Sent: Friday, February 19, 2016 11:21 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Hi Jack and Welcome to the community! When you look at the ArchivesSpace Members webpage ... any name that is blue is live linked and goes to that organization's ArchivesSpace instance. http://www.archivesspace.org/members We hope that you'll consider joining the ArchivesSpace community through contributing to the listserv with both questions and answers as you're more familiar with the tool. Kari Smith MIT Institute Archives and Special Collecitons From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jack Robertson Sent: Friday, February 19, 2016 11:08 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Dear Everyone, We at Monticello are new members of A-Space and I have been following the conversations on the lyralists Users Group with awe and admiration. The technical issues are complex and your expertise is impressive! We have been using Archon for the past four years, and are eager to migrate to A-Space. I write now to ask if I can be referred to publicly-accessible instances of A-Space? We've found and checked out the Sandbox, and now we are hoping to see how archives have made finding aids available to the public. Thanks very much, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b3aaade1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 5303 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b3aaade1/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 5303 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b3aaade1/attachment-0001.jpg> From christine.dibella at lyrasis.org Fri Feb 19 11:37:18 2016 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Fri, 19 Feb 2016 16:37:18 +0000 Subject: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Message-ID: <SN1PR08MB19677EDAA583ECFAA5601372F1A00@SN1PR08MB1967.namprd08.prod.outlook.com> Hi Jack, We will be having an ArchivesSpace Members Forum in conjunction with the SAA conference again this year, tentatively scheduled for a full day on Tuesday, August 2. It's currently in the planning stages (the full planning group is getting together next week to begin working toward more specifics), but it will provide opportunities to learn from and share information with your fellow ArchivesSpace members, new and old. So that's one opportunity to keep in mind, but I'm sure others can give you more suggestions. Christine Christine Di Bella Community Outreach and Support Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [cid:image003.png at 01CE734E.FD759D30] From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jack Robertson Sent: Friday, February 19, 2016 11:29 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Dear Kari, OK, many thanks. I'll take a close look at the blued names. I do have another "raw beginner's" question: I am contemplating going to the SAA conference in Atlanta, and I wonder how much and what types of A-Space meetings/discussions I might anticipate encountering? Do you recommend SAA as a good venue for a novice A-Spacer? Cheers, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library From: Kari R Smith [mailto:smithkr at mit.edu] Sent: Friday, February 19, 2016 11:21 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Hi Jack and Welcome to the community! When you look at the ArchivesSpace Members webpage ... any name that is blue is live linked and goes to that organization's ArchivesSpace instance. http://www.archivesspace.org/members We hope that you'll consider joining the ArchivesSpace community through contributing to the listserv with both questions and answers as you're more familiar with the tool. Kari Smith MIT Institute Archives and Special Collecitons From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jack Robertson Sent: Friday, February 19, 2016 11:08 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Spawn accession record to A-Space on the Open Internet Dear Everyone, We at Monticello are new members of A-Space and I have been following the conversations on the lyralists Users Group with awe and admiration. The technical issues are complex and your expertise is impressive! We have been using Archon for the past four years, and are eager to migrate to A-Space. I write now to ask if I can be referred to publicly-accessible instances of A-Space? We've found and checked out the Sandbox, and now we are hoping to see how archives have made finding aids available to the public. Thanks very much, --Jack * * * * * * * * * * * * * * * [NEW LOGO Color JPEG 2] Jack Robertson || Foundation Librarian Jefferson Library || Thomas Jefferson Foundation P.O. Box 316, Charlottesville, VA 22902 434-984-7545 || http://www.monticello.org/site/research-and-collections/jefferson-library -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/c5897163/attachment.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/20160219/c5897163/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 5303 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/c5897163/attachment.jpg> From akroeger at unomaha.edu Fri Feb 19 15:12:30 2016 From: akroeger at unomaha.edu (Angela Kroeger) Date: Fri, 19 Feb 2016 20:12:30 +0000 Subject: [Archivesspace_Users_Group] Publicly-accessible instances of ArchivesSpace (was RE: Spawn accession record to A-Space on the Open Internet) Message-ID: <DM2PR07MB973D3C06FC73D80FBA6A4DAD3A00@DM2PR07MB973.namprd07.prod.outlook.com> Jack Robertson asked, "I write now to ask if I can be referred to publicly-accessible instances of A-Space? We've found and checked out the Sandbox, and now we are hoping to see how archives have made finding aids available to the public." My institution's instance is publicly available: http://unomaha-public.lyrasistechnology.org/ University of Nebraska at Omaha, Criss Library Archives & Special Collections And here are a few others I'm aware of, which were linked from the members list (http://archivesspace.org/members), minus links that only went to blogs of not-yet-live sites. http://archivesspace.vmi.edu/ Virginia Military Institute http://archives.usc.edu/ University of Southern California http://archives.collections.ed.ac.uk/ University of Edinburgh http://findingaids.brandeis.edu/ Brandeis University http://findingaids.library.utc.edu/ University of Tennessee Chattanooga https://archives.tcu.edu/ Mary Couts Burnett Library, TCU http://archives.lib.cuhk.edu.hk/ Chinese University of Hong Kong Library http://archivesspace.mocanyc.org:8081/ Museum of Chinese in America I'm sure there are more public instances than those I've listed. I hope this helps! Angela Kroeger akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> Archives and Special Collections Associate Dr. C.C. and Mabel L. Criss Library University of Nebraska at Omaha (402) 554-4159 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160219/b6028727/attachment.html> From carlos.lemus at unlv.edu Mon Feb 22 12:14:37 2016 From: carlos.lemus at unlv.edu (Carlos Lemus) Date: Mon, 22 Feb 2016 09:14:37 -0800 Subject: [Archivesspace_Users_Group] Altering ASpace Public Formats Plugin Message-ID: <CAPsSwYrOe2OB1dx4o8wFSgRGG-LyaxFUyM_WGFjN5wiLACMEkg@mail.gmail.com> Hello Phil, It depends what kind of editing you want to do to the title. This will probably be the most likely scenario: under plugins/local/backend/model/ create a file called ead_serializer_ext.rb and you can change the exporter for the EAD. Since the PDF first generates this EAD this will change how your EADs *and* PDFs are exported. Here is an example of the file and where to find the original: Custom Example num tag deleted: https://github.com/l3mus/ArchivesSpace-authority-project/blob/master/unlv_ead_exporter/backend/model/ead_serializer_ext.rb#L178-L191 Original File from ArchivesSpace https://github.com/archivesspace/archivesspace/blob/master/backend/app/exporters/serializers/ead.rb#L625-L637 You may also be able to go under the stylesheets directory under your main archivesspace directory (not your plugins) and edit the as-ead-pdf.xsl file. Depends what your edits need. Where the title is in this custom stylesheets: https://github.com/l3mus/ArchivesSpace-authority-project/blob/master/unlv_ead_exporter/stylesheets/as-ead-pdf.xsl#L155 Let me know if you have any questions. Good Luck, Carlos Lemus Application Programmer, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160222/b203d33f/attachment.html> From carlos.lemus at unlv.edu Mon Feb 22 12:37:13 2016 From: carlos.lemus at unlv.edu (Carlos Lemus) Date: Mon, 22 Feb 2016 09:37:13 -0800 Subject: [Archivesspace_Users_Group] Custom Javascript for Public Interface Message-ID: <CAPsSwYpkjfp-VvBS5Cs1nmLU+zZeDcVufdwkOSKbMoZqBBACvA@mail.gmail.com> Hello Phil, Add it in a custom plugin or on your plugins/local/public/assets/javascripts . But I think the part you are missing is under plugins/local/public/views create a file called layout_head.html.erb and add the following code, this will add your javascript to the header of the public interface <%= javascript_include_tag "#{@base_url}/assets/javascripts/NAME_OF_FILE.js" %> I haven't actually tried this on the public side, but it worked on the staff side and it worked out. Try that out and let me know what happens. Good Luck, Carlos Lemus Application Programmer, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160222/b0f0a8ff/attachment.html> From psuda1 at tulane.edu Mon Feb 22 12:56:01 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Mon, 22 Feb 2016 17:56:01 +0000 Subject: [Archivesspace_Users_Group] Altering ASpace Public Formats Plugin In-Reply-To: <CAPsSwYrOe2OB1dx4o8wFSgRGG-LyaxFUyM_WGFjN5wiLACMEkg@mail.gmail.com> References: <CAPsSwYrOe2OB1dx4o8wFSgRGG-LyaxFUyM_WGFjN5wiLACMEkg@mail.gmail.com> Message-ID: <BN1PR03MB2668602E2D1A60C7B0A2EA4E5A30@BN1PR03MB266.namprd03.prod.outlook.com> Thanks Carlos. This is great. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Carlos Lemus Sent: Monday, February 22, 2016 11:15 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Cc: Carol Ou <carol.ou at unlv.edu> Subject: [Archivesspace_Users_Group] Altering ASpace Public Formats Plugin Hello Phil, It depends what kind of editing you want to do to the title. This will probably be the most likely scenario: under plugins/local/backend/model/ create a file called ead_serializer_ext.rb and you can change the exporter for the EAD. Since the PDF first generates this EAD this will change how your EADs and PDFs are exported. Here is an example of the file and where to find the original: Custom Example num tag deleted: https://github.com/l3mus/ArchivesSpace-authority-project/blob/master/unlv_ead_exporter/backend/model/ead_serializer_ext.rb#L178-L191 Original File from ArchivesSpace https://github.com/archivesspace/archivesspace/blob/master/backend/app/exporters/serializers/ead.rb#L625-L637 You may also be able to go under the stylesheets directory under your main archivesspace directory (not your plugins) and edit the as-ead-pdf.xsl file. Depends what your edits need. Where the title is in this custom stylesheets: https://github.com/l3mus/ArchivesSpace-authority-project/blob/master/unlv_ead_exporter/stylesheets/as-ead-pdf.xsl#L155 Let me know if you have any questions. Good Luck, Carlos Lemus Application Programmer, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160222/93721326/attachment.html> From vaddoniz at jhu.edu Tue Feb 23 14:43:42 2016 From: vaddoniz at jhu.edu (Valerie Addonizio) Date: Tue, 23 Feb 2016 19:43:42 +0000 Subject: [Archivesspace_Users_Group] MySQL and Notes in AT Message-ID: <36a3c7bba0f5478f9eccad5ae2a8d3c8@ESGMTWEX12.win.ad.jhu.edu> This is an AT question, and for that I apologize, but it's asked knowing some folks here have experience with MySQL as part of their migration. We have dumped AT into MySQL in order to evaluate some of our data before our migration, and I cannot seem to find the text for the Notes (i.e. Scope and Content, Bioghist). Can anyone point me to the appropriate table? Thank you. -------------------------------- Valerie Addonizio Archivist The Sheridan Libraries Johns Hopkins University vaddoniz at jhu.edu 410-516-5261 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160223/46ac8580/attachment.html> From mark.custer at yale.edu Tue Feb 23 14:49:35 2016 From: mark.custer at yale.edu (Custer, Mark) Date: Tue, 23 Feb 2016 19:49:35 +0000 Subject: [Archivesspace_Users_Group] MySQL and Notes in AT In-Reply-To: <36a3c7bba0f5478f9eccad5ae2a8d3c8@ESGMTWEX12.win.ad.jhu.edu> References: <36a3c7bba0f5478f9eccad5ae2a8d3c8@ESGMTWEX12.win.ad.jhu.edu> Message-ID: <DCB910FAD4CF9343B3E424AF5F3310252FD278EE@x10-mbx4.yu.yale.edu> Here's the table: ArchDescriptionRepeatingData But I'd be very careful about making updates there, of course (granted, the AT makes it so easy, since it stores the database username and password in plain text on any machine that accesses the AT :)). From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Valerie Addonizio Sent: Tuesday, 23 February, 2016 2:44 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] MySQL and Notes in AT This is an AT question, and for that I apologize, but it's asked knowing some folks here have experience with MySQL as part of their migration. We have dumped AT into MySQL in order to evaluate some of our data before our migration, and I cannot seem to find the text for the Notes (i.e. Scope and Content, Bioghist). Can anyone point me to the appropriate table? Thank you. -------------------------------- Valerie Addonizio Archivist The Sheridan Libraries Johns Hopkins University vaddoniz at jhu.edu<mailto:vaddoniz at jhu.edu> 410-516-5261 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160223/3738f024/attachment.html> From Joshua.D.Shaw at dartmouth.edu Wed Feb 24 08:21:15 2016 From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw) Date: Wed, 24 Feb 2016 13:21:15 +0000 Subject: [Archivesspace_Users_Group] Hide an AppConfig value in the System Info Report In-Reply-To: <0ABAD0D3-77A9-4632-BA9A-D4E46C4761D5@dartmouth.edu> References: <0ABAD0D3-77A9-4632-BA9A-D4E46C4761D5@dartmouth.edu> Message-ID: <0ACB2B26-E8EF-4540-A495-42232CF1E729@dartmouth.edu> Thanks to Mark Triggs for the solution. Apparently any AppConfig value with the string "secret" in it will be hidden in the system_info report by default. Joshua From: Joshua Shaw Reply-To: Archivesspace Users Group Date: Thursday, February 18, 2016 at 10:35 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Hide an AppConfig value in the System Info Report Hey all- I was poking around to try and find an answer for one problem and ran into another issue - of course! Anyway, we have a plugin that needs a username and password for a third party service set in the config file - at least that's the way we had it developed. Is there a way to have an AppConfig setting in the config file, but tell the application itself to not display the value in the system_info report? The system_info report already blocks the db password, so I'm hoping there's an additional flag I can set to do the same for this particular setting. If not, I'll see what I can do about obfuscating the password in some other fashion. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/548ed46f/attachment.html> From psuda1 at tulane.edu Wed Feb 24 17:24:18 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 24 Feb 2016 22:24:18 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Message-ID: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/8b51eea3/attachment.html> From sdm7g at eservices.virginia.edu Wed Feb 24 17:38:49 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 24 Feb 2016 22:38:49 +0000 Subject: [Archivesspace_Users_Group] Error on renaming repository Message-ID: <A7176D8C-9A84-49B3-986F-7335F2100120@eservices.virginia.edu> ( ArchivesSpace v1.4.2 ) I?ve deleted some repositories and attempted to rename another to the same short name as the deleted one. I get this error on attempting to save. ( I thought deleting the empty repo and renaming the other would be simpler and easier (and safer) than moving the resources into the empty one and deleting the other. Turns out not! ) Any idea how to fix this ? translation missing: en.no<http://en.no> key - Agent records cannot be identical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/c0b968b7/attachment.html> From psuda1 at tulane.edu Wed Feb 24 17:43:41 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Wed, 24 Feb 2016 22:43:41 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BN1PR03MB26668F1E23606D8E6A44D04E5A50@BN1PR03MB266.namprd03.prod.outlook.com> https://github.com/archivesspace/aReports Is the above still relevant? Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Wednesday, February 24, 2016 4:24 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/98aeb806/attachment.html> From sdm7g at eservices.virginia.edu Wed Feb 24 17:50:15 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 24 Feb 2016 22:50:15 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. ? Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/73d2eb84/attachment.html> From brianjhoffman at gmail.com Wed Feb 24 17:50:34 2016 From: brianjhoffman at gmail.com (Brian Hoffman) Date: Wed, 24 Feb 2016 17:50:34 -0500 Subject: [Archivesspace_Users_Group] Error on renaming repository In-Reply-To: <A7176D8C-9A84-49B3-986F-7335F2100120@eservices.virginia.edu> References: <A7176D8C-9A84-49B3-986F-7335F2100120@eservices.virginia.edu> Message-ID: <A8CC4970-D8A1-478D-A7A8-4465AEAB25C7@gmail.com> Hi Steve, It looks like there is still a ?corporate entity? record for the deleted repository. Go into ?agents? and delete it (or change the name sufficiently) and it should be fine. Brian > On Feb 24, 2016, at 5:38 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu> wrote: > > ( ArchivesSpace v1.4.2 ) > > > I?ve deleted some repositories and attempted to rename another to the same short name as the deleted one. > > I get this error on attempting to save. ( I thought deleting the empty repo and renaming the other would > be simpler and easier (and safer) than moving the resources into the empty one and deleting the other. > Turns out not! ) > > Any idea how to fix this ? > > > <>translation missing: en.no <http://en.no/> key - Agent records cannot be identical > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/9592b7b2/attachment.html> From mma29 at case.edu Wed Feb 24 17:53:40 2016 From: mma29 at case.edu (Mahmoud Audu) Date: Wed, 24 Feb 2016 17:53:40 -0500 Subject: [Archivesspace_Users_Group] LDAP or SAML setup Message-ID: <CAFZc6VXYpHa1mLxTxaQkZKCMTxWas8Baj-b0HXHyYVq+cWqu8g@mail.gmail.com> Good day All, i am setting up the sew system and configured the LDAP in the config.rb file on 1.4.2 AppConfig[:authentication_sources] = [{ :model => 'LDAPAuth', :hostname => 'ldap.XXXX.XXX', :port => 389, :base_dn => 'ou=people,o=,XXX.XXX,o=XXX', :username_attribute => 'uid', :attribute_map => {:cn => :givenname}, }] and when i create a new user it still asks for a password and does not authenticate on the ldap setting, am i missing something Also I noticed someone mention use of SAML, is there instruction on how that is set up? i think our IT admins prefer that option -- Thank You for your time Mahmoud Audu Programmer Analyst II, Release Manager Digital Learning and Scholarship Kelvin Smith Library Case Western Reserve University 10900 Euclid Avenue Cleveland, OH 44106-7211 Office: 216-368-3544 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160224/7a98111c/attachment.html> From Chris.Fitzpatrick at lyrasis.org Thu Feb 25 09:41:22 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Thu, 25 Feb 2016 14:41:22 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> Message-ID: <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/bb8dbade/attachment.html> From zenright at une.edu Thu Feb 25 10:37:34 2016 From: zenright at une.edu (Zachary Enright) Date: Thu, 25 Feb 2016 15:37:34 +0000 Subject: [Archivesspace_Users_Group] Locations on Public Interface Message-ID: <SN1PR0701MB1966881ACCC04310D767F999CFA60@SN1PR0701MB1966.namprd07.prod.outlook.com> We are using public interface internally only. Is there a way to make locations appear there? Zachary Enright NEOHC Archivist/UNE Special Collections Processing Archivist University of New England 11 Hills Beach Road Biddeford, ME 04005 207-602-2131 zenright at une.edu<mailto:zenright at une.edu> This e-mail may contain information that is privileged and confidential. If you suspect that you were not the intended recipient, please delete it and notify the sender as soon as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/2ca5f5b9/attachment.html> From psuda1 at tulane.edu Thu Feb 25 15:32:30 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 25 Feb 2016 20:32:30 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/7236be74/attachment.html> From Chris.Fitzpatrick at lyrasis.org Thu Feb 25 15:57:25 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Thu, 25 Feb 2016 20:57:25 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Suda, Phillip J <psuda1 at tulane.edu> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/88049e03/attachment.html> From psuda1 at tulane.edu Thu Feb 25 15:59:33 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 25 Feb 2016 20:59:33 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> MySQL. Sorry if I misunderstood your last email. Will there be another non-jasper option in the next release? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 2:57 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/cbcf2f6c/attachment.html> From Chris.Fitzpatrick at lyrasis.org Thu Feb 25 16:06:41 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Thu, 25 Feb 2016 21:06:41 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BY2PR08MB0632B9F8C2ADBC3AE8E966AFBA60@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Yeah, reports can be written with Sequel ( the ORM the backend uses ) or Jasper ( with something like Jasper studio ). You can pull out the SQL in the Jasper report and see In a MySQL session, can you try : SELECT accession.`id` AS accessionId, accession.`repo_id` AS repo_id, accession.`identifier` AS accessionNumber, accession.`title` AS title, accession.`accession_date` AS accessionDate, GetAccessionContainerSummary(accession.`id`) AS containerSummary, GetAccessionProcessed(accession.`id`) AS accessionProcessed, GetAccessionProcessedDate(accession.`id`) AS accessionProcessedDate, GetAccessionCataloged(accession.`id`) AS cataloged, GetAccessionExtent(accession.`id`) AS extentNumber, GetAccessionExtentType(accession.`id`) AS extentType, GetAccessionRightsTransferred(accession.`id`) AS rightsTransferred FROM `accession` accession WHERE (accession.`repo_id` = 2 ); ( ^^^ that's the SQL the AccessionAquired report. There might be an issue with on of the stored procedures...does the query give an error? ) b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Suda, Phillip J <psuda1 at tulane.edu> Sent: Thursday, February 25, 2016 9:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 MySQL. Sorry if I misunderstood your last email. Will there be another non-jasper option in the next release? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 2:57 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ [http://www.archivesspace.org/sites/default/files/ArchivesSpace%20Logo5.png]<http://archivesspace.org/> ArchivesSpace a community building an open-source web ...<http://archivesspace.org/> archivesspace.org Built for archives by archivists, ArchivesSpace is the open source archives information management application for managing and providing web access to archives ... ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/5c535910/attachment.html> From psuda1 at tulane.edu Thu Feb 25 16:09:56 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 25 Feb 2016 21:09:56 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BY2PR08MB0632B9F8C2ADBC3AE8E966AFBA60@BY2PR08MB063.namprd08.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB0632B9F8C2ADBC3AE8E966AFBA60@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <BN1PR03MB266C32157F2FA729E1B126AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> Ok, so test in mysql session and then alter the jasper report so that it works in the ASpace staff interface? Do I still need to run the stored procedure sql scripts or are those baked in? Thanks Chris, I appreciate it. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 3:07 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, reports can be written with Sequel ( the ORM the backend uses ) or Jasper ( with something like Jasper studio ). You can pull out the SQL in the Jasper report and see In a MySQL session, can you try : SELECT accession.`id` AS accessionId, accession.`repo_id` AS repo_id, accession.`identifier` AS accessionNumber, accession.`title` AS title, accession.`accession_date` AS accessionDate, GetAccessionContainerSummary(accession.`id`) AS containerSummary, GetAccessionProcessed(accession.`id`) AS accessionProcessed, GetAccessionProcessedDate(accession.`id`) AS accessionProcessedDate, GetAccessionCataloged(accession.`id`) AS cataloged, GetAccessionExtent(accession.`id`) AS extentNumber, GetAccessionExtentType(accession.`id`) AS extentType, GetAccessionRightsTransferred(accession.`id`) AS rightsTransferred FROM `accession` accession WHERE (accession.`repo_id` = 2 ); ( ^^^ that's the SQL the AccessionAquired report. There might be an issue with on of the stored procedures...does the query give an error? ) b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 MySQL. Sorry if I misunderstood your last email. Will there be another non-jasper option in the next release? From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 2:57 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ [http://www.archivesspace.org/sites/default/files/ArchivesSpace%20Logo5.png]<http://archivesspace.org/> ArchivesSpace a community building an open-source web ...<http://archivesspace.org/> archivesspace.org Built for archives by archivists, ArchivesSpace is the open source archives information management application for managing and providing web access to archives ... ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/c7e54d3c/attachment.html> From psuda1 at tulane.edu Thu Feb 25 16:15:36 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 25 Feb 2016 21:15:36 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB266C32157F2FA729E1B126AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB0632B9F8C2ADBC3AE8E966AFBA60@BY2PR08MB063.namprd08.prod.outlook.com> <BN1PR03MB266C32157F2FA729E1B126AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BN1PR03MB266EC948642A0ED2B7C5E52E5A60@BN1PR03MB266.namprd03.prod.outlook.com> The query gives an error: Function aspace.GetAccessioinContainerSummary does not exist. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Thursday, February 25, 2016 3:10 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Ok, so test in mysql session and then alter the jasper report so that it works in the ASpace staff interface? Do I still need to run the stored procedure sql scripts or are those baked in? Thanks Chris, I appreciate it. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 3:07 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, reports can be written with Sequel ( the ORM the backend uses ) or Jasper ( with something like Jasper studio ). You can pull out the SQL in the Jasper report and see In a MySQL session, can you try : SELECT accession.`id` AS accessionId, accession.`repo_id` AS repo_id, accession.`identifier` AS accessionNumber, accession.`title` AS title, accession.`accession_date` AS accessionDate, GetAccessionContainerSummary(accession.`id`) AS containerSummary, GetAccessionProcessed(accession.`id`) AS accessionProcessed, GetAccessionProcessedDate(accession.`id`) AS accessionProcessedDate, GetAccessionCataloged(accession.`id`) AS cataloged, GetAccessionExtent(accession.`id`) AS extentNumber, GetAccessionExtentType(accession.`id`) AS extentType, GetAccessionRightsTransferred(accession.`id`) AS rightsTransferred FROM `accession` accession WHERE (accession.`repo_id` = 2 ); ( ^^^ that's the SQL the AccessionAquired report. There might be an issue with on of the stored procedures...does the query give an error? ) b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 MySQL. Sorry if I misunderstood your last email. Will there be another non-jasper option in the next release? From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 2:57 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ [http://www.archivesspace.org/sites/default/files/ArchivesSpace%20Logo5.png]<http://archivesspace.org/> ArchivesSpace a community building an open-source web ...<http://archivesspace.org/> archivesspace.org Built for archives by archivists, ArchivesSpace is the open source archives information management application for managing and providing web access to archives ... ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/9ff759c6/attachment.html> From psuda1 at tulane.edu Thu Feb 25 16:25:04 2016 From: psuda1 at tulane.edu (Suda, Phillip J) Date: Thu, 25 Feb 2016 21:25:04 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BN1PR03MB266EC948642A0ED2B7C5E52E5A60@BN1PR03MB266.namprd03.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com>, <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB2665E1302A75EA5679F54ABE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB06337A7834D072530B57F36FBA60@BY2PR08MB063.namprd08.prod.outlook.com>, <BN1PR03MB266A1BB8EB8718FD392B89AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BY2PR08MB0632B9F8C2ADBC3AE8E966AFBA60@BY2PR08MB063.namprd08.prod.outlook.com> <BN1PR03MB266C32157F2FA729E1B126AE5A60@BN1PR03MB266.namprd03.prod.outlook.com> <BN1PR03MB266EC948642A0ED2B7C5E52E5A60@BN1PR03MB266.namprd03.prod.outlook.com> Message-ID: <BN1PR03MB2660DDCEAFA16484E42C3E5E5A60@BN1PR03MB266.namprd03.prod.outlook.com> I ran the sql/sp.sql scripts from the ASpace-Reports github repo and I didn't receive errors in my test environment. Going to restart and see what's what. Thanks, Phil From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Thursday, February 25, 2016 3:16 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 The query gives an error: Function aspace.GetAccessioinContainerSummary does not exist. From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Suda, Phillip J Sent: Thursday, February 25, 2016 3:10 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Ok, so test in mysql session and then alter the jasper report so that it works in the ASpace staff interface? Do I still need to run the stored procedure sql scripts or are those baked in? Thanks Chris, I appreciate it. Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 3:07 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, reports can be written with Sequel ( the ORM the backend uses ) or Jasper ( with something like Jasper studio ). You can pull out the SQL in the Jasper report and see In a MySQL session, can you try : SELECT accession.`id` AS accessionId, accession.`repo_id` AS repo_id, accession.`identifier` AS accessionNumber, accession.`title` AS title, accession.`accession_date` AS accessionDate, GetAccessionContainerSummary(accession.`id`) AS containerSummary, GetAccessionProcessed(accession.`id`) AS accessionProcessed, GetAccessionProcessedDate(accession.`id`) AS accessionProcessedDate, GetAccessionCataloged(accession.`id`) AS cataloged, GetAccessionExtent(accession.`id`) AS extentNumber, GetAccessionExtentType(accession.`id`) AS extentType, GetAccessionRightsTransferred(accession.`id`) AS rightsTransferred FROM `accession` accession WHERE (accession.`repo_id` = 2 ); ( ^^^ that's the SQL the AccessionAquired report. There might be an issue with on of the stored procedures...does the query give an error? ) b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 MySQL. Sorry if I misunderstood your last email. Will there be another non-jasper option in the next release? From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 2:57 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yeah, Jasper is a rather complicated...are you using a MySQL or Derby? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ [http://www.archivesspace.org/sites/default/files/ArchivesSpace%20Logo5.png]<http://archivesspace.org/> ArchivesSpace a community building an open-source web ...<http://archivesspace.org/> archivesspace.org Built for archives by archivists, ArchivesSpace is the open source archives information management application for managing and providing web access to archives ... ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Suda, Phillip J <psuda1 at tulane.edu<mailto:psuda1 at tulane.edu>> Sent: Thursday, February 25, 2016 9:32 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Running 1.4.2 on a Mac with this in the reports stanza: # Jasper Reports # (https://community.jaspersoft.com/project/jasperreports-library) # require compilation. This can be done at startup. Please note, if you are # using Java 8 and you want to compile at startup, keep this setting at false, # but be sure to use the JDK version. AppConfig[:enable_jasper] = true AppConfig[:compile_jasper] = true Here is an error I am getting: AccessionsAcquiredReport - net.sf.jasperreports.engine.JRException: Error executing SQL statement for : accessionsAcquired message - Error executing SQL statement for : accessionsAcquired backtrace - net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(net/sf/jasperreports/engine/query/JRJdbcQueryExecuter.java:240) net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:1114) net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(net/sf/jasperreports/engine/fill/JRFillDataset.java:691) net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(net/sf/jasperreports/engine/fill/JRBaseFiller.java:1314) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:931) net.sf.jasperreports.engine.fill.JRBaseFiller.fill(net/sf/jasperreports/engine/fill/JRBaseFiller.java:873) net.sf.jasperreports.engine.fill.JRFiller.fill(net/sf/jasperreports/engine/fill/JRFiller.java:87) net.sf.jasperreports.engine.JasperFillManager.fill(net/sf/jasperreports/engine/JasperFillManager.java:287) net.sf.jasperreports.engine.JasperFillManager.fillReport(net/sf/jasperreports/engine/JasperFillManager.java:760) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:22) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:85) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:21) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:131) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RUBY.fill(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:20) RUBY.render(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/reports/jdbc_report.rb:75) RUBY.generate(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:25) RUBY.report_response(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_helper.rb:39) RUBY.ArchivesSpaceService(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/reports.rb:17) org.jruby.RubyBasicObject.instance_eval(org/jruby/RubyBasicObject.java:1574) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:241) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:123) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:99) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database._transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:122) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::ThreadedConnectionPool.hold(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:87) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) Sequel::Database.transaction(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.transaction(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:98) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:122) org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:280) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) DB.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:119) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:223) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RequestContext.open(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) RESTHelpers::Endpoint.returns(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:207) org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:116) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) Sinatra::Base.compile!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1293) org.jruby.RubyProc.call(org/jruby/RubyProc.java:271) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route_eval(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:876) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:860) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:897) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.process_route(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:895) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:859) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.route!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:858) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:963) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.dispatch!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:960) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) org.jruby.RubyKernel.catch(org/jruby/RubyKernel.java:1242) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.invoke(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:946) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call!(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:794) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:780) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) ArchivesSpaceService::RequestWrappingMiddleware.call(/Users/psuda1/ArchivesSpace/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:277) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::XSSHeader.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::PathTraversal.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::JsonCsrf.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::Protection::FrameOptions.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::NullLogger.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/nulllogger.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Rack::Head.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/head.rb:9) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::ExtendedRack.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:124) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.synchronize(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1499) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Sinatra::Base.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/sinatra-1.3.6/lib/sinatra/base.rb:1417) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::Builder.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/vendor/rack-1.5.5/rack/builder.rb:138) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:64) org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::URLMap.call(/Users/psuda1/sites/archivesspaceTUL142/gems/gems/rack-1.4.7/lib/rack/urlmap.rb:49) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) Rack::Handler::Servlet.call(file:/Users/psuda1/sites/archivesspaceTUL142/gems/gems/jruby-rack-1.1.19/lib/jruby-rack-1.1.19.jar!/rack/handler/servlet.rb:22) org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(org/eclipse/jetty/servlet/ServletHandler.java:1302) org.eclipse.jetty.servlet.ServletHandler.doHandle(org/eclipse/jetty/servlet/ServletHandler.java:448) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:131) org.eclipse.jetty.security.SecurityHandler.handle(org/eclipse/jetty/security/SecurityHandler.java:524) org.eclipse.jetty.server.session.SessionHandler.doHandle(org/eclipse/jetty/server/session/SessionHandler.java:231) org.eclipse.jetty.server.handler.ContextHandler.doHandle(org/eclipse/jetty/server/handler/ContextHandler.java:1067) org.eclipse.jetty.servlet.ServletHandler.doScope(org/eclipse/jetty/servlet/ServletHandler.java:377) org.eclipse.jetty.server.session.SessionHandler.doScope(org/eclipse/jetty/server/session/SessionHandler.java:192) org.eclipse.jetty.server.handler.ContextHandler.doScope(org/eclipse/jetty/server/handler/ContextHandler.java:1001) org.eclipse.jetty.server.handler.ScopedHandler.handle(org/eclipse/jetty/server/handler/ScopedHandler.java:129) org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(org/eclipse/jetty/server/handler/ContextHandlerCollection.java:250) org.eclipse.jetty.server.handler.HandlerWrapper.handle(org/eclipse/jetty/server/handler/HandlerWrapper.java:111) org.eclipse.jetty.server.Server.handle(org/eclipse/jetty/server/Server.java:360) org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(org/eclipse/jetty/server/AbstractHttpConnection.java:454) org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:890) org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(org/eclipse/jetty/server/AbstractHttpConnection.java:944) org.eclipse.jetty.http.HttpParser.parseNext(org/eclipse/jetty/http/HttpParser.java:630) org.eclipse.jetty.http.HttpParser.parseAvailable(org/eclipse/jetty/http/HttpParser.java:230) org.eclipse.jetty.server.AsyncHttpConnection.handle(org/eclipse/jetty/server/AsyncHttpConnection.java:77) org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:622) org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(org/eclipse/jetty/io/nio/SelectChannelEndPoint.java:46) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(org/eclipse/jetty/util/thread/QueuedThreadPool.java:603) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(org/eclipse/jetty/util/thread/QueuedThreadPool.java:538) java.lang.Thread.run(java/lang/Thread.java:745) From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Chris Fitzpatrick Sent: Thursday, February 25, 2016 8:41 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. - Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/f8ca50af/attachment.html> From sdm7g at eservices.virginia.edu Thu Feb 25 16:25:25 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Thu, 25 Feb 2016 21:25:25 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> Message-ID: <817F3E2A-DD47-4202-9892-4FA102C9CA11@eservices.virginia.edu> OK. Adding back that directory fixes the repository report for me. ? Steve. On Feb 25, 2016, at 9:41 AM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. ? Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/e6a126b6/attachment.html> From sdm7g at eservices.virginia.edu Thu Feb 25 16:48:37 2016 From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Thu, 25 Feb 2016 21:48:37 +0000 Subject: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 In-Reply-To: <817F3E2A-DD47-4202-9892-4FA102C9CA11@eservices.virginia.edu> References: <BN1PR03MB266B66EB49D6DAD140B2D6EE5A50@BN1PR03MB266.namprd03.prod.outlook.com> <7B9FCD22-5A04-4012-AE89-963BE2D4435A@eservices.virginia.edu> <BY2PR08MB063E4C9808CF21CEB09FD77FBA60@BY2PR08MB063.namprd08.prod.outlook.com> <817F3E2A-DD47-4202-9892-4FA102C9CA11@eservices.virginia.edu> Message-ID: <2BD2DA6C-C9A7-47AC-99F9-72F16D0AC975@eservices.virginia.edu> On Feb 25, 2016, at 4:25 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote: OK. Adding back that directory fixes the repository report for me. ? Steve. However, I?m getting similar SQL errors as Phillip on some other reports. On Feb 25, 2016, at 9:41 AM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote: Hi, Yes, the reports/static directory was removed awhile back...and i can't remember why. I think it was because there was an expectation that Jasper would replace all reports functionality. You can see the folder here: https://github.com/archivesspace/archivesspace/tree/v1.2.0/reports/static But I'll add these back as well for the next release. b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> Sent: Wednesday, February 24, 2016 11:50 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Jasper Reports in 1.4.2 Most of the reports work for me in 1.4.2. on Mac but some of them, like RepositoryReport, always fail. I did not seem to have to do any font installation on Mac as I did on Linux, but maybe there are some remaining font issues on Mac as well, since the failing stacktrace is in in ITextFontResolver.java RepositoryReport - java.lang.NullPointerException message - backtrace - org.xhtmlrenderer.swing.NaiveUserAgent.getBinaryResource(org/xhtmlrenderer/swing/NaiveUserAgent.java:228) org.xhtmlrenderer.pdf.ITextFontResolver.importFontFaces(org/xhtmlrenderer/pdf/ITextFontResolver.java:97) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:178) org.xhtmlrenderer.pdf.ITextRenderer.setDocument(org/xhtmlrenderer/pdf/ITextRenderer.java:142) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497) RUBY.render_pdf(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:46) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/pdf_response.rb:19) RUBY.generate(/projects/Archivespace/archivesspace/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/reports/report_response.rb:28) NamesListReport and ResourcesListReport though, for two examples, work without errors. ? Steve M. On Feb 24, 2016, at 5:24 PM, Suda, Phillip J <psuda1 at TULANE.EDU<mailto:psuda1 at TULANE.EDU>> wrote: Is anyone having trouble with reports in ASpace 1.4.2? I have AppConfigs set to true in Reports stanzas. I am running against a MySql database. It looks like the areports jar file is included with the distribution. I am testing this locally on a Mac. Am I missing something? Thanks, Phil Phillip Suda Systems Librarian Howard-Tilton Memorial Library Tulane University psuda1 at tulane.edu<mailto:psuda1 at tulane.edu> 504-865-5607 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/e817cc45/attachment.html> From Joshua.D.Shaw at dartmouth.edu Thu Feb 25 17:57:10 2016 From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw) Date: Thu, 25 Feb 2016 22:57:10 +0000 Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? Message-ID: <CA897AE7-1BCD-488F-93D2-83BAB467C5CE@dartmouth.edu> Just a quick question for the group. I'm testing how long and resource intensive resequencing would be for our data (it's about a 9GB SOLR index and about 450k archival objects attached to 3500+/- resources. Some of the resources have many thousands of related child AOs. One has 60k+. Anyway, I started the resequence locally and finally stopped it 10 hours later and 100GB+ temp space on my drive. Anyone have a ballpark feel for whether this is out of line (I think it probably is!) or should I have just waited a bit more? We are running the container management plugin under 1.3.0 since that may be a factor. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160225/1cc34118/attachment.html> From Chris.Fitzpatrick at lyrasis.org Fri Feb 26 08:01:30 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Fri, 26 Feb 2016 13:01:30 +0000 Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? In-Reply-To: <CA897AE7-1BCD-488F-93D2-83BAB467C5CE@dartmouth.edu> References: <CA897AE7-1BCD-488F-93D2-83BAB467C5CE@dartmouth.edu> Message-ID: <BY2PR08MB063ACF22AF2D863ADCB800EFBA70@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Where is this disk space being used? In the MySQL directories? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu> Sent: Thursday, February 25, 2016 11:57 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? Just a quick question for the group. I'm testing how long and resource intensive resequencing would be for our data (it's about a 9GB SOLR index and about 450k archival objects attached to 3500+/- resources. Some of the resources have many thousands of related child AOs. One has 60k+. Anyway, I started the resequence locally and finally stopped it 10 hours later and 100GB+ temp space on my drive. Anyone have a ballpark feel for whether this is out of line (I think it probably is!) or should I have just waited a bit more? We are running the container management plugin under 1.3.0 since that may be a factor. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160226/af1d4556/attachment.html> From Joshua.D.Shaw at dartmouth.edu Fri Feb 26 08:25:04 2016 From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw) Date: Fri, 26 Feb 2016 13:25:04 +0000 Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? Message-ID: <1E9890B3-C702-4E48-83B8-01D15322AF9E@dartmouth.edu> Hey Chris- It was a temp file somewhere in the usual suspects in Mac OS (/tmp or /private/var/folders, etc). I killed the process before it ate my entire remaining free drive space and before I thought about tracking down the exact location (silly me!). It wasn't immediately obvious what was being written, but it wasn't a mysql log or anything like that in the mysql directories. I'm gonna give it another go today and see if I can be a bit more specific about what and where for the temp file(s). I'm also going to set the cron times for SOLR and another plugin process that runs as a background job for Jan 1 so that they can't interfere. It still seems that 100GB(or more) is huge for something like this, unless the process was looping over and over, but the output log indicated that it was still chugging along when I killed it. Do you have a ballpark for what I should expect to see for usage and duration? I know its probably really dependent on the complexity and number of related objects, but any back of the envelope guess would be good to know. Thanks! Joshua From: Chris Fitzpatrick Reply-To: Archivesspace Users Group Date: Friday, February 26, 2016 at 8:01 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resequencing - Disk Space used? Hi, Where is this disk space being used? In the MySQL directories? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu<mailto:Joshua.D.Shaw at dartmouth.edu>> Sent: Thursday, February 25, 2016 11:57 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? Just a quick question for the group. I'm testing how long and resource intensive resequencing would be for our data (it's about a 9GB SOLR index and about 450k archival objects attached to 3500+/- resources. Some of the resources have many thousands of related child AOs. One has 60k+. Anyway, I started the resequence locally and finally stopped it 10 hours later and 100GB+ temp space on my drive. Anyone have a ballpark feel for whether this is out of line (I think it probably is!) or should I have just waited a bit more? We are running the container management plugin under 1.3.0 since that may be a factor. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160226/02d808ae/attachment.html> From Chris.Fitzpatrick at lyrasis.org Fri Feb 26 11:19:58 2016 From: Chris.Fitzpatrick at lyrasis.org (Chris Fitzpatrick) Date: Fri, 26 Feb 2016 16:19:58 +0000 Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? In-Reply-To: <1E9890B3-C702-4E48-83B8-01D15322AF9E@dartmouth.edu> References: <1E9890B3-C702-4E48-83B8-01D15322AF9E@dartmouth.edu> Message-ID: <BY2PR08MB0630A2EE1650D84A693AD04FBA70@BY2PR08MB063.namprd08.prod.outlook.com> Hi, Hm, so..when you do the resync, you can do it without indexer, frontend, public UI turned on. Also...maybe sure you didn't turn on your MySQL slow-query log or any other log ( i forget that sometimes )... b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu> Sent: Friday, February 26, 2016 2:25 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resequencing - Disk Space used? Hey Chris- It was a temp file somewhere in the usual suspects in Mac OS (/tmp or /private/var/folders, etc). I killed the process before it ate my entire remaining free drive space and before I thought about tracking down the exact location (silly me!). It wasn't immediately obvious what was being written, but it wasn't a mysql log or anything like that in the mysql directories. I'm gonna give it another go today and see if I can be a bit more specific about what and where for the temp file(s). I'm also going to set the cron times for SOLR and another plugin process that runs as a background job for Jan 1 so that they can't interfere. It still seems that 100GB(or more) is huge for something like this, unless the process was looping over and over, but the output log indicated that it was still chugging along when I killed it. Do you have a ballpark for what I should expect to see for usage and duration? I know its probably really dependent on the complexity and number of related objects, but any back of the envelope guess would be good to know. Thanks! Joshua From: Chris Fitzpatrick Reply-To: Archivesspace Users Group Date: Friday, February 26, 2016 at 8:01 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resequencing - Disk Space used? Hi, Where is this disk space being used? In the MySQL directories? b,chris. Chris Fitzpatrick | Developer, ArchivesSpace Skype: chrisfitzpat | Phone: 918.236.6048 http://archivesspace.org/ [http://www.archivesspace.org/sites/default/files/ArchivesSpace%20Logo5.png]<http://archivesspace.org/> ArchivesSpace a community building an open-source web ...<http://archivesspace.org/> archivesspace.org Built for archives by archivists, ArchivesSpace is the open source archives information management application for managing and providing web access to archives ... ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu<mailto:Joshua.D.Shaw at dartmouth.edu>> Sent: Thursday, February 25, 2016 11:57 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Resequencing - Disk Space used? Just a quick question for the group. I'm testing how long and resource intensive resequencing would be for our data (it's about a 9GB SOLR index and about 450k archival objects attached to 3500+/- resources. Some of the resources have many thousands of related child AOs. One has 60k+. Anyway, I started the resequence locally and finally stopped it 10 hours later and 100GB+ temp space on my drive. Anyone have a ballpark feel for whether this is out of line (I think it probably is!) or should I have just waited a bit more? We are running the container management plugin under 1.3.0 since that may be a factor. Thanks! Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160226/4ad64426/attachment.html> From NHOSBURGH at Rollins.edu Mon Feb 29 11:36:51 2016 From: NHOSBURGH at Rollins.edu (Nathan Hosburgh) Date: Mon, 29 Feb 2016 16:36:51 +0000 Subject: [Archivesspace_Users_Group] AS Public interface examples Message-ID: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> Could some folks who are up live on AS provide me URLs to your public interface? Also, is there any more detailed info on configuring the AS public interface besides this: http://archivesspace.github.io/archivesspace/user/getting-started/ We got our Archon DB migrated and we have a URL pointing to our AS staff interface at https://aspace.rollins.edu/ but not sure how to set up the AS public interface. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu<mailto:nhosburgh at rollins.edu> (407) 691-1157 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/32eee882/attachment.html> From flemingj at uncw.edu Mon Feb 29 11:41:42 2016 From: flemingj at uncw.edu (Fleming, Jason) Date: Mon, 29 Feb 2016 16:41:42 +0000 Subject: [Archivesspace_Users_Group] AS Public interface examples In-Reply-To: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> References: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> Message-ID: <CY1PR0601MB10997C51E9C9E4214077C924A7BA0@CY1PR0601MB1099.namprd06.prod.outlook.com> Nathan, Ours is not live yet, but I have been working on a screencast that I think I will be ready to submit sometime this week documenting the steps I took to do some basic public interface configuration. These are the goals we were looking to accomplish at the start of the project: -altering CSS -adding a branded image at the top -changing welcome text -altering footer -modifying the Navigation options If you have any specific questions about how to get started I would be happy to point you in the right direction -Jason Jason Fleming Information Technology Librarian 601 South College Road | Wilmington, NC 28403-5990 T: 910-962-2675<tel:910-962-2675> | flemingj at uncw.edu<mailto:flemingj at uncw.edu> http://library.uncw.edu<http://library.uncw.edu/> -Jason From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:37 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] AS Public interface examples Could some folks who are up live on AS provide me URLs to your public interface? Also, is there any more detailed info on configuring the AS public interface besides this: http://archivesspace.github.io/archivesspace/user/getting-started/ We got our Archon DB migrated and we have a URL pointing to our AS staff interface at https://aspace.rollins.edu/ but not sure how to set up the AS public interface. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu<mailto:nhosburgh at rollins.edu> (407) 691-1157 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/9d2c66d9/attachment.html> From NHOSBURGH at Rollins.edu Mon Feb 29 11:47:42 2016 From: NHOSBURGH at Rollins.edu (Nathan Hosburgh) Date: Mon, 29 Feb 2016 16:47:42 +0000 Subject: [Archivesspace_Users_Group] AS Public interface examples In-Reply-To: <CY1PR0601MB10997C51E9C9E4214077C924A7BA0@CY1PR0601MB1099.namprd06.prod.outlook.com> References: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> <CY1PR0601MB10997C51E9C9E4214077C924A7BA0@CY1PR0601MB1099.namprd06.prod.outlook.com> Message-ID: <CY1PR02MB13981C3D71191C670C08A4DAB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> Thanks, Jason - this will be helpful and I'll contact you off-list. Nate From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fleming, Jason Sent: Monday, February 29, 2016 11:42 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Nathan, Ours is not live yet, but I have been working on a screencast that I think I will be ready to submit sometime this week documenting the steps I took to do some basic public interface configuration. These are the goals we were looking to accomplish at the start of the project: -altering CSS -adding a branded image at the top -changing welcome text -altering footer -modifying the Navigation options If you have any specific questions about how to get started I would be happy to point you in the right direction -Jason Jason Fleming Information Technology Librarian 601 South College Road | Wilmington, NC 28403-5990 T: 910-962-2675<tel:910-962-2675> | flemingj at uncw.edu<mailto:flemingj at uncw.edu> http://library.uncw.edu<http://library.uncw.edu/> -Jason From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:37 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] AS Public interface examples Could some folks who are up live on AS provide me URLs to your public interface? Also, is there any more detailed info on configuring the AS public interface besides this: http://archivesspace.github.io/archivesspace/user/getting-started/ We got our Archon DB migrated and we have a URL pointing to our AS staff interface at https://aspace.rollins.edu/ but not sure how to set up the AS public interface. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu<mailto:nhosburgh at rollins.edu> (407) 691-1157 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/f7b99e05/attachment.html> From JacobDB at vmi.edu Mon Feb 29 11:52:01 2016 From: JacobDB at vmi.edu (Jacob, Diane B) Date: Mon, 29 Feb 2016 16:52:01 +0000 Subject: [Archivesspace_Users_Group] AS Public interface examples In-Reply-To: <CY1PR02MB13981C3D71191C670C08A4DAB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> References: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> <CY1PR0601MB10997C51E9C9E4214077C924A7BA0@CY1PR0601MB1099.namprd06.prod.outlook.com> <CY1PR02MB13981C3D71191C670C08A4DAB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> Message-ID: <6fe56e60248f46c3b448da13101446d3@vmi.edu> Nate, Our public interface is here http://archivesspace.vmi.edu/ Diane Diane B. Jacob Head, Archives & Records Management Virginia Military Institute Preston Library Lexington, VA 24450 540-464-7566 www.vmi.edu/archives<http://www.vmi.edu/archives> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:48 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Thanks, Jason - this will be helpful and I'll contact you off-list. Nate From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fleming, Jason Sent: Monday, February 29, 2016 11:42 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Nathan, Ours is not live yet, but I have been working on a screencast that I think I will be ready to submit sometime this week documenting the steps I took to do some basic public interface configuration. These are the goals we were looking to accomplish at the start of the project: -altering CSS -adding a branded image at the top -changing welcome text -altering footer -modifying the Navigation options If you have any specific questions about how to get started I would be happy to point you in the right direction -Jason Jason Fleming Information Technology Librarian 601 South College Road | Wilmington, NC 28403-5990 T: 910-962-2675<tel:910-962-2675> | flemingj at uncw.edu<mailto:flemingj at uncw.edu> http://library.uncw.edu<http://library.uncw.edu/> -Jason From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:37 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] AS Public interface examples Could some folks who are up live on AS provide me URLs to your public interface? Also, is there any more detailed info on configuring the AS public interface besides this: http://archivesspace.github.io/archivesspace/user/getting-started/ We got our Archon DB migrated and we have a URL pointing to our AS staff interface at https://aspace.rollins.edu/ but not sure how to set up the AS public interface. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu<mailto:nhosburgh at rollins.edu> (407) 691-1157 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/8629bbbf/attachment.html> From NHOSBURGH at Rollins.edu Mon Feb 29 12:10:07 2016 From: NHOSBURGH at Rollins.edu (Nathan Hosburgh) Date: Mon, 29 Feb 2016 17:10:07 +0000 Subject: [Archivesspace_Users_Group] AS Public interface examples In-Reply-To: <6fe56e60248f46c3b448da13101446d3@vmi.edu> References: <CY1PR02MB1398488E80E0C021F52CEAEEB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> <CY1PR0601MB10997C51E9C9E4214077C924A7BA0@CY1PR0601MB1099.namprd06.prod.outlook.com> <CY1PR02MB13981C3D71191C670C08A4DAB9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> <6fe56e60248f46c3b448da13101446d3@vmi.edu> Message-ID: <CY1PR02MB1398454EACDD69E737879876B9BA0@CY1PR02MB1398.namprd02.prod.outlook.com> Hi Diane. Thanks for sharing - the site looks great. What is your URL for the staff interface? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jacob, Diane B Sent: Monday, February 29, 2016 11:52 AM To: 'Archivesspace Users Group' Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Nate, Our public interface is here http://archivesspace.vmi.edu/ Diane Diane B. Jacob Head, Archives & Records Management Virginia Military Institute Preston Library Lexington, VA 24450 540-464-7566 www.vmi.edu/archives<http://www.vmi.edu/archives> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:48 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Thanks, Jason - this will be helpful and I'll contact you off-list. Nate From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Fleming, Jason Sent: Monday, February 29, 2016 11:42 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] AS Public interface examples Nathan, Ours is not live yet, but I have been working on a screencast that I think I will be ready to submit sometime this week documenting the steps I took to do some basic public interface configuration. These are the goals we were looking to accomplish at the start of the project: -altering CSS -adding a branded image at the top -changing welcome text -altering footer -modifying the Navigation options If you have any specific questions about how to get started I would be happy to point you in the right direction -Jason Jason Fleming Information Technology Librarian 601 South College Road | Wilmington, NC 28403-5990 T: 910-962-2675<tel:910-962-2675> | flemingj at uncw.edu<mailto:flemingj at uncw.edu> http://library.uncw.edu<http://library.uncw.edu/> -Jason From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Nathan Hosburgh Sent: Monday, February 29, 2016 11:37 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] AS Public interface examples Could some folks who are up live on AS provide me URLs to your public interface? Also, is there any more detailed info on configuring the AS public interface besides this: http://archivesspace.github.io/archivesspace/user/getting-started/ We got our Archon DB migrated and we have a URL pointing to our AS staff interface at https://aspace.rollins.edu/ but not sure how to set up the AS public interface. Thanks Nate Nathan Hosburgh Discovery & Systems Librarian Rollins College, Olin Library 1000 Holt Avenue Winter Park, FL 32789 nhosburgh at rollins.edu<mailto:nhosburgh at rollins.edu> (407) 691-1157 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/08c25aaa/attachment.html> From jcarll at radcliffe.harvard.edu Mon Feb 29 12:16:08 2016 From: jcarll at radcliffe.harvard.edu (Carll, Johanna) Date: Mon, 29 Feb 2016 17:16:08 +0000 Subject: [Archivesspace_Users_Group] Ingesting nested <list> elements Message-ID: <DM3PR07MB2171EE141AE0E65B138A48A59ABA0@DM3PR07MB2171.namprd07.prod.outlook.com> We have over 5,000 <list> elements in our finding aids, many of them containing nested <list>s. Since the AS data model only allows for simple ordered lists, we are finding that while our <list> elements with nested <list>s are ingesting, much of the data in the element is missing. For example, when attempting to ingest the below <list> found within an <arrangement> tag, only the <item> elements in the final nested <list> ingest <list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Series I. Biographical and personal</item><item>Series II. Gwynne family</item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series III. Correspondence<list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Subseries A. Personal</item><item>Subseries B. Professional</item></list></item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series IV. Writings<list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Subseries A. Articles</item><item>Subseries B. Monographs </item><item>Subseries C. Pamphlets</item></list></item><item> Series V. Elizabeth David Ltd.</item><item> Series VI. Recipes and research</item><item> Series VII. Artemis Cooper and Jill Norman</item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series VIII. Photographs and oversized<list><item>Subseries A. Photographs </item><item>Subseries B. Oversized</item></list></item></list></arrangement> Has anyone else encountered this issue? If so, how have you addressed the problem? Thanks Johanna Carll Archivist and Metadata Specialist Schlesinger Library Radcliffe Institute for Advanced Study Harvard University 10 Garden Street Cambridge, MA 02138 617-495-8524 jcarll at radcliffe.harvard.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/626dc23c/attachment.html> From noah.huffman at duke.edu Mon Feb 29 16:11:53 2016 From: noah.huffman at duke.edu (Noah Huffman) Date: Mon, 29 Feb 2016 21:11:53 +0000 Subject: [Archivesspace_Users_Group] Ingesting nested <list> elements In-Reply-To: <DM3PR07MB2171EE141AE0E65B138A48A59ABA0@DM3PR07MB2171.namprd07.prod.outlook.com> References: <DM3PR07MB2171EE141AE0E65B138A48A59ABA0@DM3PR07MB2171.namprd07.prod.outlook.com> Message-ID: <BLUPR0501MB8337EF3302AAB19C947F512E6BA0@BLUPR0501MB833.namprd05.prod.outlook.com> Hi Johanna, We had a similar problem at Duke with nested lists in <controlaccess>. We decided just to flatten the hierarchy to get the data to import. If you're not concerned about preserving the hierarchy (indentation?) of your items and just want the data to import, I've attached some XSLT that will copy an entire EAD as is, but "un-nest" lists within <arrangement>. It should output all <item> elements at the same level no matter how deeply they are nested. Here's the end result for your example: <arrangement> <list> <item>Series I. Biographical and personal</item> <item>Series II. Gwynne family</item> <item>Series III. Correspondence</item> <item>Subseries A. Personal</item> <item>Subseries B. Professional</item> <item>Series IV. Writings</item> <item>Subseries A. Articles</item> <item>Subseries B. Monographs </item> <item>Subseries C. Pamphlets</item> <item>Series V. Elizabeth David Ltd.</item> <item>Series VI. Recipes and research</item> <item>Series VII. Artemis Cooper and Jill Norman</item> <item>Series VIII. Photographs and oversized</item> <item>Subseries A. Photographs </item> <item>Subseries B. Oversized</item> </list> </arrangement> If you have nested lists outside of arrangement, you'd need to modify the script to account for that. I haven't tested this extensively, so disclaimers as usual. -Noah ================ Noah Huffman Archivist for Metadata, Systems, and Digital Records David M. Rubenstein Rare Book & Manuscript Library Duke University | 919-660-5982 http://library.duke.edu/rubenstein/ From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Carll, Johanna Sent: Monday, February 29, 2016 12:16 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Ingesting nested <list> elements We have over 5,000 <list> elements in our finding aids, many of them containing nested <list>s. Since the AS data model only allows for simple ordered lists, we are finding that while our <list> elements with nested <list>s are ingesting, much of the data in the element is missing. For example, when attempting to ingest the below <list> found within an <arrangement> tag, only the <item> elements in the final nested <list> ingest <list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Series I. Biographical and personal</item><item>Series II. Gwynne family</item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series III. Correspondence<list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Subseries A. Personal</item><item>Subseries B. Professional</item></list></item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series IV. Writings<list><file:///C:\Users\jac811\Desktop\sch01172.xml><item>Subseries A. Articles</item><item>Subseries B. Monographs </item><item>Subseries C. Pamphlets</item></list></item><item> Series V. Elizabeth David Ltd.</item><item> Series VI. Recipes and research</item><item> Series VII. Artemis Cooper and Jill Norman</item><item><file:///C:\Users\jac811\Desktop\sch01172.xml> Series VIII. Photographs and oversized<list><item>Subseries A. Photographs </item><item>Subseries B. Oversized</item></list></item></list></arrangement> Has anyone else encountered this issue? If so, how have you addressed the problem? Thanks Johanna Carll Archivist and Metadata Specialist Schlesinger Library Radcliffe Institute for Advanced Study Harvard University 10 Garden Street Cambridge, MA 02138 617-495-8524 jcarll at radcliffe.harvard.edu<mailto:jcarll at radcliffe.harvard.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/17864c78/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ead_list_denester.xsl Type: text/xml Size: 1449 bytes Desc: ead_list_denester.xsl URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160229/17864c78/attachment.xml>