Re: [Archivesspace_Users_Group] more punctuation issues with MARC exports
Hello, We’re still encountering this MARC export error in 2.5.2; since today I had circled back to trying to figure out why it was happening, I thought I’d ping the list again to see if anyone else has encountered it. I did a little bit more testing today and it seems like we only encounter the erratic punctuation if an agent is linked more than once in a resource, and if one of the links has the role of Subject. Multiple links punctuate normally in the MARC export if their roles are Creator and Source. This continues to be the case even with all of our plugins deactivated. Happy to submit this as a bug report if others have encountered the issue. thanks! -k From: on behalf of Kevin Clair Reply-To: Archivesspace Group Date: Tuesday, December 4, 2018 at 3:58 PM To: Archivesspace Group Subject: [Archivesspace_Users_Group] more punctuation issues with MARC exports Hello, We’re testing 2.5.1 here at DU because it fixes some bugs our archivists have encountered, and in so doing I’ve found some strangeness with 110s and 610s in the MARC export. When we have resources where the same agent is a creator and a subject of the resource, the exporter will always append a comma to the name even if it’s a 610 and there’s no subfield E present, and will always append a period after the comma even if it’s a 110 and there is a subfield E present. We have some MARC export customizations in our local plugins, but this error persists even if I turn the local plugins off in our configuration. The error moves from agent to agent, e.g. if I change the creator from “Central City Opera House Association (Central City, Colo.)” to “Central City Opera Festival (Central City, Colo.),” the erratic punctuation in subfield A will move to the latter corporate name from the former. Attached is example output (this is from our 2.5.1 instance with no active MARC customizations). I wanted to send a note to the list to see if anyone else has seen anything similar before I submit a JIRA ticket for it. thanks! -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] Unable to view collections (public interface) after upgrading from 1.5.1 to 2.5.2
Hi,
We had the same issue going from 1.5.x to 2.x. The agent_representation_id
value in the repository table was null. I 'fixed' it by making a small edit
to the Repository and saving it. The column then got populated.
We migrated from Archon as well. I have sql dumps from each upgrade and it
appears that the column was never populated to begin with.
On Wed, Apr 17, 2019 at 10:14 AM Flanagan, Patrick
wrote:
> Thanks for the information! I should have added that this repository was
> originally migrated from Archon, so it's possible some strangeness carried
> over from the migration.
>
>
> I ran *SELECT CONCAT('/agents/agent_corporate_entity/', id) AS 'url_stub'
> FROM agent_corporate_entity WHERE id IN (SELECT agent_representation_id
> FROM repository); *but received an empty set. Doing *select
> agent_representation_id from repository;* comes up with two rows of NULL.
> I tried editing each of the agents and saving them again, as well as the
> resource itself, but that didn't seem to correct it, unfortunately. If this
> is the issue, is there a way I can correct them in SQL en masse?
>
>
> As for everything showing under /repositories - I think so, but I'm not
> sure. It looks fine to me, unless 2.5.2 would have added more data. It
> looks like this:
>
>
>
>
> It's considered repository 2 in the URLs, but that's normal for our
> instances.
>
>
> Thanks again,
>
>
> ~Patrick Flanagan
>
> *KLN Applications Administrator*
>
> *Keystone Library Network Hub*
> --
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Blake Carver
> *Sent:* Monday, April 15, 2019 2:24:37 PM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Unable to view collections
> (public interface) after upgrading from 1.5.1 to 2.5.2
>
> We've seen this (infrequently) with upgrades from 1.5.x to 2.x: If I was a
> betting man, I'd bet a/the repository has lost its agent representation
> (which needs to be a reference to a corporate entity). If you try to view
> the repository in the admin "/repositories" page (that is under SYSTEM
> "manage repositories"), does it show everything it should?
>
> Could also be a plugin.
> --
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Flanagan, Patrick
> *Sent:* Monday, April 15, 2019 1:57 PM
> *To:* archivesspace_users_group@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=0="=(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"))=AND=true=\=json=-exclude_by_default:true=suppressed:false=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: type="application/ld+json">
> [15f88748-5b17-4145-97f9-9fef25df3ba0] 4: <%=
> JSON.pretty_generate(@result.metadata).html_safe %>
> [15f88748-5b17-4145-97f9-9fef25df3ba0] 5:
> [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
Re: [Archivesspace_Users_Group] Unable to view collections (public interface) after upgrading from 1.5.1 to 2.5.2
Thanks for the information! I should have added that this repository was
originally migrated from Archon, so it's possible some strangeness carried over
from the migration.
I ran SELECT CONCAT('/agents/agent_corporate_entity/', id) AS 'url_stub' FROM
agent_corporate_entity WHERE id IN (SELECT agent_representation_id FROM
repository); but received an empty set. Doing select agent_representation_id
from repository; comes up with two rows of NULL. I tried editing each of the
agents and saving them again, as well as the resource itself, but that didn't
seem to correct it, unfortunately. If this is the issue, is there a way I can
correct them in SQL en masse?
As for everything showing under /repositories - I think so, but I'm not sure.
It looks fine to me, unless 2.5.2 would have added more data. It looks like
this:
[cid:34181aac-e517-4c8a-802f-e4a857a6bbd1]
It's considered repository 2 in the URLs, but that's normal for our instances.
Thanks again,
~Patrick Flanagan
KLN Applications Administrator
Keystone Library Network Hub
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of Blake
Carver
Sent: Monday, April 15, 2019 2:24:37 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Unable to view collections (public
interface) after upgrading from 1.5.1 to 2.5.2
We've seen this (infrequently) with upgrades from 1.5.x to 2.x: If I was a
betting man, I'd bet a/the repository has lost its agent representation (which
needs to be a reference to a corporate entity). If you try to view the
repository in the admin "/repositories" page (that is under SYSTEM "manage
repositories"), does it show everything it should?
Could also be a plugin.
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of
Flanagan, Patrick
Sent: Monday, April 15, 2019 1:57 PM
To: archivesspace_users_group@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=0="=(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"))=AND=true=\=json=-exclude_by_default:true=suppressed:false=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:
[15f88748-5b17-4145-97f9-9fef25df3ba0] 4: <%=
JSON.pretty_generate(@result.metadata).html_safe %>
[15f88748-5b17-4145-97f9-9fef25df3ba0] 5:
[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:9cb69a6e-a056-46ca-bddb-34bc600b5cab]
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
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
