Re: [Archivesspace_Users_Group] Error when searching in archivesspace v2.1.1

[Custer, Mark]

Ahhh, thanks for figuring that out Steve!!!  I'll update the JIRA ticket with 
this info.


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Majewski, Steven Dennis (sdm7g)
Sent: Wednesday, 23 August, 2017 3:57 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1


PS to previous note:

I initially tried using ancestor display_string as the default, but that failed.

Although the ancestor resource has a display_string attribute containing the 
date, that does not appear to be indexed into the PUI index results returned by 
search results.  So getting that probably requires changes to the indexer as 
well.



ancestor.fetch( 'level' ) did work as alternative default:

<%= link_to process_mixed_content(ancestor.fetch('title', 
ancestor.fetch('level'))).html_safe, app_prefix(ancestor.fetch('uri')) %>



-- Steve Majewski / UVA Alderman Library

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
>
 on behalf of Majewski, Steven Dennis (sdm7g) 
>
Sent: Wednesday, August 23, 2017 3:29:39 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1




It looks like adding a default arg to the fetch method is also a quick fix:

diff --git a/public/app/views/shared/_result.html.erb 
b/public/app/views/shared/_result.html.erb



index 01bfc6c..3434f05 100644



--- a/public/app/views/shared/_result.html.erb



+++ b/public/app/views/shared/_result.html.erb



@@ -50,7 +50,7 @@



   <% result.ancestors.each do |ancestor| %>



 /



 



-<%= link_to 
process_mixed_content(ancestor.fetch('title')).html_safe, 
app_prefix(ancestor.fetch('uri')) %>



+<%= link_to process_mixed_content(ancestor.fetch('title', 
'[untitled]')).html_safe, app_prefix(ancestor.fetch('uri')) %>



 



   <% end %>



 <% else %>



-- Steve Majewski / UVA Alderman Library

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
>
 on behalf of Custer, Mark >
Sent: Wednesday, August 23, 2017 1:52:50 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1

Neal, Lance: thanks for diagnosing this issue!

The PUI search results should definitely still work in this case.  We had 
archival objects in our test corpus with missing titles, so I'm pretty sure 
that this worked at some point, but it's definitely not working now, as you've 
noticed.  I think the simple fix would be to fall back to the display title if 
a title doesn't exist (the display title in ASpace concatenates the title and 
the first date subrecord together, so in the cases of a missing title, you 
might wind up with something like "1880-1889" as the search result link, or the 
breadcrumb link in the "Found In" section of the search results).  I've just 
added a JIRA ticket to capture this bug: 
https://archivesspace.atlassian.net/browse/AR-1869

Mark



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Wednesday, 23 August, 2017 1:18 PM
To: Archivesspace Users Group 
>
Subject: Re: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1


Hi Lance,



We've experienced this issue as well, in search results after the move to 2.1. 
We recently finished some testing on it. Our findings suggest this is directly 
related to archival objects that possess a date subrecord but no title. For 
these records, a search in the new public interface spawns the 'something went 
wrong' message-from our error logs and yours, it looks like the search 
parameters are looking for titles and when those do not exist, and it breaks 
the search. Although an archival object title in ASpace is 

[Archivesspace_Users_Group] Internal server error on public 'fill_request' page

[Kevin Clair]

Hello,

I'm working on getting e-mail requests set up in our new PUI, and have been 
encountering the following errors in the logs when ArchivesSpace attempts to 
display the request success page (key errors in bold):

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: I, [2017-08-23T12:42:10.718672 #20482]  INFO -- : 
[c90e77e0-4387-4281-b38e-a533031ca293] Completed 500 Internal Server Error in 
8505ms

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T12:42:10.752777 #20482] FATAL -- : 
[c90e77e0-4387-4281-b38e-a533031ca293]

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T12:42:10.753720 #20482] FATAL -- : 
[c90e77e0-4387-4281-b38e-a533031ca293] ActionView::Template::Error (undefined 
method `app_prefix' for #<#:0x5ff8ec0>):

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T12:42:10.764493 #20482] FATAL -- : 
[c90e77e0-4387-4281-b38e-a533031ca293] 4:   Record Requested
[c90e77e0-4387-4281-b38e-a533031ca293] 5:   Title: <%= 
@request.title %>
[c90e77e0-4387-4281-b38e-a533031ca293] 6:   <% url = 
"#{AppConfig[:public_proxy_url].sub(/\/^/, '')}#{@request.request_uri}" %>
[c90e77e0-4387-4281-b38e-a533031ca293] 7:   URL: <%= 
link_to url, app_prefix(url) %>
[c90e77e0-4387-4281-b38e-a533031ca293] 8: 
[c90e77e0-4387-4281-b38e-a533031ca293] 9:
[c90e77e0-4387-4281-b38e-a533031ca293]10: 

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T12:42:10.766101 #20482] FATAL -- : 
[c90e77e0-4387-4281-b38e-a533031ca293]

Aug 23, 2017 12:42:10 PM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T12:42:10.774380 #20482] FATAL -- : 
[c90e77e0-4387-4281-b38e-a533031ca293] 
app/views/request_mailer/request_received_email.html.erb:7:in 
`_app_views_request_mailer_request_received_email_html_erb__2099221818_2268'
[c90e77e0-4387-4281-b38e-a533031ca293] app/mailers/request_mailer.rb:7:in 
`request_received_email'
[c90e77e0-4387-4281-b38e-a533031ca293] 
app/controllers/requests_controller.rb:11:in `make_request'

Has anyone else encountered anything like this? I tried to fix it using a 
plugin to replace "app_prefix(url)" with some other link but I couldn't get the 
plugin to override the original page. Thanks in advance for any help provided!  
-k
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Error when searching in archivesspace v2.1.1

[Custer, Mark]

Neal, Lance: thanks for diagnosing this issue!

The PUI search results should definitely still work in this case.  We had 
archival objects in our test corpus with missing titles, so I'm pretty sure 
that this worked at some point, but it's definitely not working now, as you've 
noticed.  I think the simple fix would be to fall back to the display title if 
a title doesn't exist (the display title in ASpace concatenates the title and 
the first date subrecord together, so in the cases of a missing title, you 
might wind up with something like "1880-1889" as the search result link, or the 
breadcrumb link in the "Found In" section of the search results).  I've just 
added a JIRA ticket to capture this bug: 
https://archivesspace.atlassian.net/browse/AR-1869

Mark



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Wednesday, 23 August, 2017 1:18 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1


Hi Lance,



We've experienced this issue as well, in search results after the move to 2.1. 
We recently finished some testing on it. Our findings suggest this is directly 
related to archival objects that possess a date subrecord but no title. For 
these records, a search in the new public interface spawns the 'something went 
wrong' message-from our error logs and yours, it looks like the search 
parameters are looking for titles and when those do not exist, and it breaks 
the search. Although an archival object title in ASpace is conditionally 
required when a date subrecord is present, the search does not seem to 
recognize that flexibility.



In addition, it appears when a keyword search is conducted across all record 
types, and any one of the related archival objects (for example, a sibling or 
child archival object in a series) does not have a title, any search for terms 
in that series will also generate the 'something went wrong' search result.



We've been able to reproduce this result and repair it. Adding the titles 
resolved the search error. I also created a simple test record with archival 
objects that do not possess titles; a search within the titles gives the broken 
search result but once the title is entered and saved, the search works. I've 
attached an EAD export of that test resource record (we used unique terms for 
us, 'AEIOU' and 'fuzzy' so we could pinpoint the test). You'll see that the 
series in the EAD export does not have a  field.



We've made the local decision to require title fields for all archival objects.



I hope this helps identity trouble areas. Perhaps the public interface search 
could be updated to work with archival objects lacking titles-or the archival 
object title field made required?


Neal
--
Neal Harmeyer
Digital Archivist
Archives and Special Collections
Purdue University Libraries
harme...@purdue.edu






-Original Message-
From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
DUPRE, LANCE
Sent: Wednesday, August 23, 2017 11:55 AM
To: Archivesspace Users Group 
>
Subject: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1



Hello,



We have a test instance of archivespace 2.1.1 that is throwing the "Something 
went wrong" error when a search is performed searching all record types and for 
a keyword. It is only throwing the error for certain words (ex tree, navy and 
possibly others) and other words return results fine. The * wildcard also 
returns results.



Our production instance, on archivesspace 1.5.4 does not throw these errors 
when I do the same search.



I have attached the logs I think are relevant to the search.



Any help would be appreciated.



Thanks,







, [2017-08-23T11:48:57.060531 #11297] DEBUG -- : Thread-2022: GET 
/repositories/9/accessions?all_ids=true_since=1503433821 [session: 
#"search_indexer", :login_time=>2017-08-23 
10:57:40 -0400, :expirable=>false}, 
@id="35ccdf0821cbc8065adf7f1576eb02e254564cd1484d6cc5dec6c673ae3ba709", 
@system_mtime=2017-08-23 15:48:27 UTC>] D, [2017-08-23T11:48:57.061902 #11297] 
DEBUG -- : Thread-2022: Post-processed params: {"all_ids"=>true, 
"modified_since"=>1503433821, :repo_id=>9} Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.063591 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec]



Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.064606 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] 

Re: [Archivesspace_Users_Group] Error when searching in archivesspace v2.1.1

[Harmeyer, Neal A]

Hi Lance,



We've experienced this issue as well, in search results after the move to 2.1. 
We recently finished some testing on it. Our findings suggest this is directly 
related to archival objects that possess a date subrecord but no title. For 
these records, a search in the new public interface spawns the 'something went 
wrong' message-from our error logs and yours, it looks like the search 
parameters are looking for titles and when those do not exist, and it breaks 
the search. Although an archival object title in ASpace is conditionally 
required when a date subrecord is present, the search does not seem to 
recognize that flexibility.



In addition, it appears when a keyword search is conducted across all record 
types, and any one of the related archival objects (for example, a sibling or 
child archival object in a series) does not have a title, any search for terms 
in that series will also generate the 'something went wrong' search result.



We've been able to reproduce this result and repair it. Adding the titles 
resolved the search error. I also created a simple test record with archival 
objects that do not possess titles; a search within the titles gives the broken 
search result but once the title is entered and saved, the search works. I've 
attached an EAD export of that test resource record (we used unique terms for 
us, 'AEIOU' and 'fuzzy' so we could pinpoint the test). You'll see that the 
series in the EAD export does not have a  field.



We've made the local decision to require title fields for all archival objects.



I hope this helps identity trouble areas. Perhaps the public interface search 
could be updated to work with archival objects lacking titles-or the archival 
object title field made required?


Neal
--
Neal Harmeyer
Digital Archivist
Archives and Special Collections
Purdue University Libraries
harme...@purdue.edu






-Original Message-
From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
DUPRE, LANCE
Sent: Wednesday, August 23, 2017 11:55 AM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Error when searching in archivesspace 
v2.1.1



Hello,



We have a test instance of archivespace 2.1.1 that is throwing the "Something 
went wrong" error when a search is performed searching all record types and for 
a keyword. It is only throwing the error for certain words (ex tree, navy and 
possibly others) and other words return results fine. The * wildcard also 
returns results.



Our production instance, on archivesspace 1.5.4 does not throw these errors 
when I do the same search.



I have attached the logs I think are relevant to the search.



Any help would be appreciated.



Thanks,







, [2017-08-23T11:48:57.060531 #11297] DEBUG -- : Thread-2022: GET 
/repositories/9/accessions?all_ids=true_since=1503433821 [session: 
#"search_indexer", :login_time=>2017-08-23 
10:57:40 -0400, :expirable=>false}, 
@id="35ccdf0821cbc8065adf7f1576eb02e254564cd1484d6cc5dec6c673ae3ba709", 
@system_mtime=2017-08-23 15:48:27 UTC>] D, [2017-08-23T11:48:57.061902 #11297] 
DEBUG -- : Thread-2022: Post-processed params: {"all_ids"=>true, 
"modified_since"=>1503433821, :repo_id=>9} Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.063591 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec]



Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.064606 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] ActionView::Template::Error (key not 
found: :title):



D, [2017-08-23T11:48:57.066191 #11297] DEBUG -- : Thread-2022: Responded with 
[200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, 
must-revalidate, max-age=0", "Content-Length"=>"3"}, ["[]\n"]]... in 6ms Aug 
23, 2017 11:48:57 AM org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.065756 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] 50:   <% 
result.ancestors.each do |ancestor| %>

[11861f8d-4ed2-494e-93d5-bde230321aec] 51: /

[11861f8d-4ed2-494e-93d5-bde230321aec] 52: 

[11861f8d-4ed2-494e-93d5-bde230321aec] 53: <%= link_to 
process_mixed_content(ancestor.fetch('title')).html_safe, 
app_prefix(ancestor.fetch('uri')) %>

[11861f8d-4ed2-494e-93d5-bde230321aec] 54: 

[11861f8d-4ed2-494e-93d5-bde230321aec] 55:   <% end %>

[11861f8d-4ed2-494e-93d5-bde230321aec] 56: <% else %>



Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log

INFO: F, [2017-08-23T11:48:57.066453 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec]



Aug 23, 2017 11:48:57 AM 

Re: [Archivesspace_Users_Group] rights types and upgrade to 2.1.1

[Jason Loeffler]

Thanks, Christine. Yes, I observed Payten's notes at ANW-114 and that
clarifies the issue. All records were migrated to new values correctly and
remarkably quickly.

Our remaining issue is with the re-configuration of default value
templates. For interested parties, I've added my notes to ANW-114 that
further clarifies the issue. We were able to resolve our immediate issue
with MySQL queries. Not sure if this is a bug or a feature but it would be
nice to make the rights statements contained in default templates PREMIS
compliant in a future release.

Best, Jason




On Wed, Aug 23, 2017 at 9:37 AM, Christine Di Bella <
christine.dibe...@lyrasis.org> wrote:

> Dear Jason,
>
>
>
> Making rights type a non-configurable list was part of the rights
> specification that was distributed prior to this enhanced functionality
> being built into 2.1.0. The intent of this particular change was to
> maximize compatibility with PREMIS, but to allow “other” as a value, the
> specifics of which users could then specify within the Other Rights Basis
> field. Other Rights Basis is a configurable list.
>
>
>
> The JIRA with all the parts of the specification is here:
> https://archivesspace.atlassian.net/browse/ANW-123
>
>
>
> This is the JIRA explaining the migration path: https://archivesspace.
> atlassian.net/browse/ANW-114
>
>
>
> Did your custom rights statements get migrated as Other with an Other
> Rights Basis that matches your previous label? We didn’t receive much
> feedback from people during testing about how their rights migrations went
> and whether what they expected to see was there, though it was something we
> asked for in the original release candidate announcement. During the
> migration, previous rights statement info. is also backed up into a table
> called rights_statement_pre_088. Are you seeing that in your installation?
>
>
>
> We do know that if someone adds or deletes a value to/from a
> non-configurable list (which can’t be done through the Manage Controlled
> Value Lists area in the staff interface, but potentially can be done by
> working directly with the database) that it affects other parts of the
> application, which would explain the other behavior you describe.
>
>
>
> Christine
>
>
>
> Christine Di Bella
>
> ArchivesSpace Program Manager
>
> christine.dibe...@lyrasis.org
>
> 800.999.8558 x2905 <(800)%20999-8558>
>
> 678-235-2905 <(678)%20235-2905>
>
> cdibella13 (Skype)
>
>
>
> [image: ASpaceOrgHomeMedium]
>
>
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:
> archivesspace_users_group-boun...@lyralists.lyrasis.org] *On Behalf Of *Jason
> Loeffler
> *Sent:* Tuesday, August 22, 2017 3:06 PM
> *To:* Archivesspace Users Group  lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] rights types and upgrade to 2.1.1
>
>
>
> Following an upgrade from 1.5.1 to 2.1.1, we're seeing an issue with
> rights statements.
>
>
>
> It looks like the upgrade blows away our custom rights statement rights
> types from the controlled value rights type enumeration leaving us with
> only the new default types: copyright, license, statute, other.
>
>
>
> In practice, attempting to edit default values for resources components
> yields the following
> .
> This also prevents the creation of new resource components. Furthermore,
> existing records have their rights statement rights type are overwriting
> with 'other'.
>
>
>
> Just wanted to inquire whether this is replicable for anyone else or
> whether there is an additional upgrade task or documentation I'm missing.
>
>
>
> Thanks, JL
>
>
>
> Jason Loeffler
>
> Technology Consultant | The American Academy in Rome
>
> Brooklyn, New York
>
> ja...@minorscience.com
>
> (347) 405-0826
>
> minorscience (Skype)
>
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] FW: Registration Open: Digital Preservation Management Workshop - Oct 16-20, 2017 at RISD Museum

[Kari R Smith]

-- Apologies for cross-posting this announcement of a training 
course ---

We are happy to announce that the five-day Digital Preservation Management 
Workshop directed by Nancy Y. McGovern is taking place this October 16-20, 2017 
hosted by Rhode Island School of Design Library in Providence, Rhode Island.

Are you responsible for digital preservation at your organization?  Are you 
interested in learning the standards, resources, policies, and work flows 
integral to a successful program?  Do you want to join a cohort of similar 
professionals as you develop your skills and organizational readiness?  Come 
learn how to implement short-term strategies for long-term problems.

Apply beginning August 23:  http://bit.ly/dpworkshop2017Oct

This week-long workshop that will be held at the RISD Museum includes 
interactive presentations, group discussions, exercises, and individual 
assignments. The week opens with an with an exploration of digital practice 
principles and tools that sets the stage for the week and closes with practical 
next steps sessions to frame attendees follow up work at their home 
institutions. Additional instructors include Kari Smith and Courtney Mumma.

Workshop attendees explore the range of components needed to develop an 
effective and sustainable digital preservation program and if interested, 
identify members in this cohort to work with on next steps. Workshop materials 
include action plans for organizations to complete when participants return to 
their institutions. Action plans result in organization-specific plans that 
incorporate technical, financial, organizational, and policy aspects 
encompassing the full life cycle of digital objects.

The workshop focuses on strategies for organizations to implement now, while 
research and active development goes forward in creating longer-term solutions 
that can be incorporated into the digital preservation framework provided as 
individual programs grow and evolve. By the conclusion of the workshop managers 
of digital content are equipped with the know-how to establish or build their 
digital preservation program through a standards-based approach.

The workshop is limited to 25 participants in order to provide for substantial 
discussions and group work.  Tuition fee is $1,200.00 and includes four lunches 
and a group dinner -- no payment is required at time of application.  Questions 
can be directed to: dpmw-managem...@mit.edu

More information about the Workshop series, DP Management Tools, and the DPM 
Tutorial are at http://dpworkshop.org



Kari R. Smith
Digital Archivist and Program Head for Born-digital Archives
Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries, Cambridge, Massachusetts
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/  
@karirene69

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

[Archivesspace_Users_Group] Error when searching in archivesspace v2.1.1

[DUPRE, LANCE]

Hello,

We have a test instance of archivespace 2.1.1 that is throwing the "Something 
went wrong" error when a search is performed searching all record types and for 
a keyword. It is only throwing the error for certain words (ex tree, navy and 
possibly others) and other words return results fine. The * wildcard also 
returns results.

Our production instance, on archivesspace 1.5.4 does not throw these errors 
when I do the same search.

I have attached the logs I think are relevant to the search.

Any help would be appreciated.

Thanks,



, [2017-08-23T11:48:57.060531 #11297] DEBUG -- : Thread-2022: GET 
/repositories/9/accessions?all_ids=true_since=1503433821 [session: 
#"search_indexer", :login_time=>2017-08-23 
10:57:40 -0400, :expirable=>false}, 
@id="35ccdf0821cbc8065adf7f1576eb02e254564cd1484d6cc5dec6c673ae3ba709", 
@system_mtime=2017-08-23 15:48:27 UTC>]
D, [2017-08-23T11:48:57.061902 #11297] DEBUG -- : Thread-2022: Post-processed 
params: {"all_ids"=>true, "modified_since"=>1503433821, :repo_id=>9}
Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T11:48:57.063591 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec]   

Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T11:48:57.064606 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] ActionView::Template::Error (key not 
found: :title):

D, [2017-08-23T11:48:57.066191 #11297] DEBUG -- : Thread-2022: Responded with 
[200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, 
must-revalidate, max-age=0", "Content-Length"=>"3"}, ["[]\n"]]... in 6ms
Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T11:48:57.065756 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] 50:   <% 
result.ancestors.each do |ancestor| %>
[11861f8d-4ed2-494e-93d5-bde230321aec] 51: /
[11861f8d-4ed2-494e-93d5-bde230321aec] 52: 
[11861f8d-4ed2-494e-93d5-bde230321aec] 53: <%= link_to 
process_mixed_content(ancestor.fetch('title')).html_safe, 
app_prefix(ancestor.fetch('uri')) %>
[11861f8d-4ed2-494e-93d5-bde230321aec] 54: 
[11861f8d-4ed2-494e-93d5-bde230321aec] 55:   <% end %>
[11861f8d-4ed2-494e-93d5-bde230321aec] 56: <% else %>

Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T11:48:57.066453 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec]   

Aug 23, 2017 11:48:57 AM 
org.eclipse.jetty.server.handler.ContextHandler$Context log
INFO: F, [2017-08-23T11:48:57.067003 #11297] FATAL -- : 
[11861f8d-4ed2-494e-93d5-bde230321aec] app/views/shared/_result.html.erb:53:in 
`block in _app_views_shared__result_html_erb___496965727_2290'
[11861f8d-4ed2-494e-93d5-bde230321aec] app/views/shared/_result.html.erb:50:in 
`_app_views_shared__result_html_erb___496965727_2290'
[11861f8d-4ed2-494e-93d5-bde230321aec] 
app/views/search/search_results.html.erb:72:in `block in 
_app_views_search_search_results_html_erb___490211956_2278'
[11861f8d-4ed2-494e-93d5-bde230321aec] 
app/views/search/search_results.html.erb:71:in 
`_app_views_search_search_results_html_erb___490211956_2278'
[11861f8d-4ed2-494e-93d5-bde230321aec] 
app/controllers/search_controller.rb:59:in `search'

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

Re: [Archivesspace_Users_Group] rights types and upgrade to 2.1.1

[Christine Di Bella]

Dear Jason,

Making rights type a non-configurable list was part of the rights specification 
that was distributed prior to this enhanced functionality being built into 
2.1.0. The intent of this particular change was to maximize compatibility with 
PREMIS, but to allow “other” as a value, the specifics of which users could 
then specify within the Other Rights Basis field. Other Rights Basis is a 
configurable list.

The JIRA with all the parts of the specification is here: 
https://archivesspace.atlassian.net/browse/ANW-123

This is the JIRA explaining the migration path: 
https://archivesspace.atlassian.net/browse/ANW-114

Did your custom rights statements get migrated as Other with an Other Rights 
Basis that matches your previous label? We didn’t receive much feedback from 
people during testing about how their rights migrations went and whether what 
they expected to see was there, though it was something we asked for in the 
original release candidate announcement. During the migration, previous rights 
statement info. is also backed up into a table called rights_statement_pre_088. 
Are you seeing that in your installation?

We do know that if someone adds or deletes a value to/from a non-configurable 
list (which can’t be done through the Manage Controlled Value Lists area in the 
staff interface, but potentially can be done by working directly with the 
database) that it affects other parts of the application, which would explain 
the other behavior you describe.

Christine

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

[ASpaceOrgHomeMedium]




From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Jason Loeffler
Sent: Tuesday, August 22, 2017 3:06 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] rights types and upgrade to 2.1.1

Following an upgrade from 1.5.1 to 2.1.1, we're seeing an issue with rights 
statements.

It looks like the upgrade blows away our custom rights statement rights types 
from the controlled value rights type enumeration leaving us with only the new 
default types: copyright, license, statute, other.

In practice, attempting to edit default values for resources components yields 
the 
following.
 This also prevents the creation of new resource components. Furthermore, 
existing records have their rights statement rights type are overwriting with 
'other'.

Just wanted to inquire whether this is replicable for anyone else or whether 
there is an additional upgrade task or documentation I'm missing.

Thanks, JL

Jason Loeffler
Technology Consultant | The American Academy in Rome
Brooklyn, New York
ja...@minorscience.com
(347) 405-0826
minorscience (Skype)

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