[Archivesspace_Users_Group] Unable to view collections (public interface) after upgrading from 1.5.1 to 2.5.2

[Custer, Mark]

Patrick,

Just taking a quick look at this, I wonder if the issue might have something to do with the relationship between the repository record and its corresponding corporate agent record?  Do both of those records (the repository record and the corporate agent record associated with the repo that owns any affected resource records) show up fine in the staff interface?  I've heard of similar issues happening, but as it's not happened in our system, I've never seen exactly what causes that problem.

Do you have the ability to run SQL queries?  If so, then this query should provide the URL suffix that you could use to check out the agent records that are linked to each repository record (since I don't think that the staff interface surfaces how the two records are connected):

SELECT
    CONCAT('/agents/agent_corporate_entity/', id) AS 'url_stub'
FROM
    agent_corporate_entity
WHERE
    id IN (SELECT  agent_representation_id FROM repository)
;

I don't *think* that those corporate agent records should need to be published not to cause an error, although if that's the case then that might be a bug.  I'm just curious if the agent records show up at all in the staff interface, or if editing those records (even just a meaningless edit) will solve the issue in the public interface after the indexer picks those up again.  Ditto that the repository record itself might need to be re-indexed, but again, I'm just guessing since I haven't encountered this issue first hand, although I know it has impacted other folks.

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Flanagan, Patrick
Sent: Monday, 15 April, 2019 1:58 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Unable to view collections (public interface) after upgrading from 1.5.1 to 2.5.2


I've also attempted to step the upgrades down to 2.5.1, 2.4.0, then 2.1.0, to see if some aspect of the migration was responsible; but the issue remains regardless. The staff interface is not impacted to the best of my knowledge.



Upon clicking any collection in thew new public interface I'm greeted with the We're sorry, but something went wrong error message. The log  file indicates the following error at the same time:


Apr 15, 2019 11:28:16 AM org.apache.solr.core.SolrCore execute
INFO: [collection1] webapp= path=/select params={facet=true&start=0&csv.encapsulator="&q=(id:("\/repositories\/2\/top_containers\/1143")+OR+id:("\/repositories\/2\/top_containers\/1144")+OR+id:("\/repositories\/2\/top_containers\/1145")+OR+id:("\/repositories\/2\/top_containers\/1146")+OR+id:("\/repositories\/2\/top_containers\/1147")+OR+id:("\/repositories\/2\/top_containers\/1149"))&q.op=AND&csv.header=true&csv.escape=\&wt=json&fq=-exclude_by_default:true&fq=suppressed:false&rows=500} hits=6 status=0 QTime=2
F, [2019-04-15T11:28:16.525748 #54143] FATAL -- : [15f88748-5b17-4145-97f9-9fef25df3ba0]
F, [2019-04-15T11:28:16.526196 #54143] FATAL -- : [15f88748-5b17-4145-97f9-9fef25df3ba0] ActionView::Template::Error (undefined method `[]' for nil:NilClass):
F, [2019-04-15T11:28:16.527030 #54143] FATAL -- : [15f88748-5b17-4145-97f9-9fef25df3ba0]     1: <% if @result && @result.respond_to?(:metadata) %>
[15f88748-5b17-4145-97f9-9fef25df3ba0]     2:
[15f88748-5b17-4145-97f9-9fef25df3ba0]     3: <script type="application/ld+json">
[15f88748-5b17-4145-97f9-9fef25df3ba0]     4: <%= JSON.pretty_generate(@result.metadata).html_safe %>
[15f88748-5b17-4145-97f9-9fef25df3ba0]     5: </script>
[15f88748-5b17-4145-97f9-9fef25df3ba0]     6: <% end %>
F, [2019-04-15T11:28:16.527849 #54143] FATAL -- : [15f88748-5b17-4145-97f9-9fef25df3ba0]
F, [2019-04-15T11:28:16.528196 #54143] FATAL -- : [15f88748-5b17-4145-97f9-9fef25df3ba0] app/models/resource.rb:104:in `metadata'
[15f88748-5b17-4145-97f9-9fef25df3ba0] app/views/shared/_metadata.html.erb:4:in `_app_views_shared__metadata_html_erb___128582640_2336'
[15f88748-5b17-4145-97f9-9fef25df3ba0] app/views/layouts/application.html.erb:24:in `_app_views_layouts_application_html_erb___683597418_2334'



I investigated a little bit and found a reference to authority ID around that line. It's worth noting that this particular institution seems to have authority ID blank for every agent, which makes the record look like this in the staff interface:



[cid:image001.png at 01D4F395.78816690]



This aspect of the problem might be unrelated, but it was the only lead I had.



Any advice would be welcome! I thought I would ask here before heading to Jira with it.



Thanks,



~Patrick Flanagan

KLN Applications Administrator

Keystone Library Network Hub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190415/0a5f5452/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39697 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190415/0a5f5452/attachment.png>