Re: [Archivesspace_Users_Group] Classifications

[Kennedy, Nancy]

Thanks Christie.  I see now .. I can add the classification parent or child 
from the accessions edit screen, even if I can't from the classification child 
screen itself.

Are you all using the PUI?  I wonder if it makes sense to make the 
classification available in the EAD.

Nancy Kennedy
Smithsonian Institution
kenne...@si.edu

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[archivesspace_users_group-boun...@lyralists.lyrasis.org] on behalf of Christie 
Peterson [cpeter...@smith.edu]
Sent: Friday, September 15, 2017 5:13 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Classifications

Hi Nancy,

We're using the classifications strictly for our College Archives, which has a 
long-standing Record Group system in place. We're not using it for the Sophia 
Smith Collection or the Mortimer Rare Book Collection, both of which are set up 
as separate repositories within our ASpace instance.

The classifications mirror the pre-existing RG system, so, for example, RG12 is 
"Special Events and People," and the child classification 12.01 is 
"Anniversaries."

[Screen Shot 2017-09-15 at 5.10.27 PM.png]
We just went into production with this, so I can't comment on how well it works 
yet, but it seemed like the logical thing for us to do. We do have accessions 
linked to both top-level and child-level classifications, so that functionality 
appears to work.

Best,

Christie Peterson

On Fri, Sep 15, 2017 at 4:52 PM Kennedy, Nancy 
> wrote:
All –
How are you using classifications at your institutions?  In particular, can 
anyone speak to the nested ‘child’ classifications? I’ve been looking at the 
feature in our test installations, but am interested to see if anyone is using 
this out in the wild.  What’s the purpose of nested child classifications, 
given that it seems I can only attach a resource/accession/digital object to 
the top parent classification term?

I see AR-1884 suggesting 
that classifications be available across multiple repositories. I can see some 
benefit there, though so far, most of my users have seemed to prefer the idea 
that classifications would be repo specific. We haven’t adopted classifications 
yet, but if it looks like they would become global, I’d like to get more 
details sooner than later.


Thanks!


Nancy Kennedy
Smithsonian Institution
kenne...@si.edu

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
--
��
Christie S. Peterson

Head of Technical Services for Special Collections
Smith College
Northampton, Mass.
413-585-2996
cpeter...@smith.edu

pronouns: she/her/hers
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Classifications

[Christie Peterson]

Hi Nancy,

We're using the classifications strictly for our College Archives, which
has a long-standing Record Group system in place. We're not using it for
the Sophia Smith Collection or the Mortimer Rare Book Collection, both of
which are set up as separate repositories within our ASpace instance.

The classifications mirror the pre-existing RG system, so, for example,
RG12 is "Special Events and People," and the child classification 12.01 is
"Anniversaries."

[image: Screen Shot 2017-09-15 at 5.10.27 PM.png]
We just went into production with this, so I can't comment on how well it
works yet, but it seemed like the logical thing for us to do. We do have
accessions linked to both top-level and child-level classifications, so
that functionality appears to work.

Best,

Christie Peterson

On Fri, Sep 15, 2017 at 4:52 PM Kennedy, Nancy  wrote:

> All –
>
> How are you using classifications at your institutions?  In particular,
> can anyone speak to the nested ‘child’ classifications? I’ve been looking
> at the feature in our test installations, but am interested to see if
> anyone is using this out in the wild.  What’s the purpose of nested child
> classifications, given that it seems I can only attach a
> resource/accession/digital object to the top parent classification term?
>
>
>
> I see AR-1884 
> suggesting that classifications be available across multiple repositories.
> I can see some benefit there, though so far, most of my users have seemed
> to prefer the idea that classifications would be repo specific. We haven’t
> adopted classifications yet, but if it looks like they would become global,
> I’d like to get more details sooner than later.
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Nancy Kennedy
>
> Smithsonian Institution
>
> kenne...@si.edu
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
-- 

Christie S. Peterson

Head of Technical Services for Special Collections
Smith College
Northampton, Mass.
413-585-2996
cpeter...@smith.edu

pronouns: she/her/hers
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Classifications

[Kennedy, Nancy]

All -
How are you using classifications at your institutions?  In particular, can 
anyone speak to the nested 'child' classifications? I've been looking at the 
feature in our test installations, but am interested to see if anyone is using 
this out in the wild.  What's the purpose of nested child classifications, 
given that it seems I can only attach a resource/accession/digital object to 
the top parent classification term?

I see AR-1884 suggesting 
that classifications be available across multiple repositories. I can see some 
benefit there, though so far, most of my users have seemed to prefer the idea 
that classifications would be repo specific. We haven't adopted classifications 
yet, but if it looks like they would become global, I'd like to get more 
details sooner than later.


Thanks!


Nancy Kennedy
Smithsonian Institution
kenne...@si.edu

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

[Archivesspace_Users_Group] no indexer_pui_state files in backup.sh output

[Kevin Clair]

Hello,

I’ve noticed with the 2.* releases that when running scripts/backup.sh, the 
indexer_pui_state files aren’t included in the output, only the indexer_state 
files. Is that an issue I should submit to JIRA or am I missing something?

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] 2.1.2 re-indexing loop

[Stanonik, Ronald]

I notice a repeating error and stacktrace in the log about an unhandled 
exception.

E, [2017-09-15T09:45:13.168412 #10788] ERROR -- : Thread-5342: Unhandled 
exception!
E, [2017-09-15T09:45:13.168722 #10788] ERROR -- :
key not found: :
org/jruby/RubyHash.java:1189:in `fetch'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/ancestor_listing.rb:63:in
 `root_record'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/ancestor_listing.rb:22:in
 `block in add_ancestors'
org/jruby/RubyArray.java:1734:in `each'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/ancestor_listing.rb:12:in
 `add_ancestors'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/archival_object.rb:69:in
 `sequel_to_jsonmodel'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:105:in
 `listing_response'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in
 `handle_listing'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:95:in
 `block in ArchivesSpaceService'
org/jruby/RubyBasicObject.java:1687:in `instance_eval'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:280:in
 `block in returns'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:111:in
 `block in open'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:75:in
 `block in transaction'
/usr/local/archivesspace/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:134:in
 `_transaction'
/usr/local/archivesspace/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:108:in
 `block in transaction'
/usr/local/archivesspace/gems/gems/sequel-4.20.0/lib/sequel/connection_pool/threaded.rb:98:in
 `hold'
/usr/local/archivesspace/gems/gems/sequel-4.20.0/lib/sequel/database/connecting.rb:255:in
 `synchronize'
/usr/local/archivesspace/gems/gems/sequel-4.20.0/lib/sequel/database/transactions.rb:97:in
 `transaction'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:74:in
 `transaction'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:110:in
 `block in open'
org/jruby/RubyFixnum.java:305:in `times'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:107:in
 `open'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:432:in
 `block in DB'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:262:in
 `block in returns'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in
 `open'
/usr/local/archivesspace-v2.1.2/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:230:in
 `block in returns'
org/jruby/RubyMethod.java:111:in `call'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1611:in 
`block in compile!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in 
`block in route!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:994:in 
`route_eval'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in 
`block in route!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1015:in 
`block in process_route'
org/jruby/RubyKernel.java:1120:in `catch'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in 
`process_route'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:973:in 
`block in route!'
org/jruby/RubyArray.java:1734:in `each'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:972:in 
`route!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1085:in 
`block in dispatch!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 
`block in invoke'
org/jruby/RubyKernel.java:1120:in `catch'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 
`invoke'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1082:in 
`dispatch!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:907:in 
`block in call!'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 
`block in invoke'
org/jruby/RubyKernel.java:1120:in `catch'
/usr/local/archivesspace/gems/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 
`invoke'

Re: [Archivesspace_Users_Group] 2.1.2 re-indexing loop

[Christine Di Bella]

Hi Ron,

This sounds like it might be particular to something with your data or 
installation, so I'm going to put a tech support ticket in for you on this. 
(You'll see another message about that directly to you in a minute.) Our tech 
folks will ask you for your full log to see if they can spot the cause.

Sometimes when this has happened there is orphaned data that no longer meets 
ArchivesSpace requirements and that prevents the initial indexing from actually 
completing, but it's possible that something else is going on. It'd be great if 
when it gets resolved you would share the solution back to the lists.

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 
Stanonik, Ronald
Sent: Friday, September 15, 2017 12:48 PM
To: archivesspace_users_group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] 2.1.2 re-indexing loop

I recently upgraded to 2.1.2 and it seems to be in an indexing loop.

I restarted the application.

I removed the solr index and restarted the application.

In the log I see it counting up

Staff Indexer [2017-09-15 07:42:21 -0700] ~~~ Indexed 185825 of 212959 
archival_object records in repository SC
...
Staff Indexer [2017-09-15 03:50:30 -0700] ~~~ Indexed 201525 of 212959 
archival_object records in repository SC

But then

Staff Indexer [2017-09-15 04:09:49 -0700] ~~~ Indexed 25 of 212959 
archival_object records in repository SC

Since yesterday it has re-indexed ten times.

The resulting constant re-indexing causes a high load average and slow 
performance for users.

Any suggestions?

Thanks,

Ron

ps.  I also posted this question to 
https://groups.google.com/forum/#!forum/archivesspace.  Sorry if that is 
redundant.
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] 2.1.2 re-indexing loop

[Stanonik, Ronald]

I recently upgraded to 2.1.2 and it seems to be in an indexing loop.

I restarted the application.

I removed the solr index and restarted the application.

In the log I see it counting up

Staff Indexer [2017-09-15 07:42:21 -0700] ~~~ Indexed 185825 of 212959 
archival_object records in repository SC
...
Staff Indexer [2017-09-15 03:50:30 -0700] ~~~ Indexed 201525 of 212959 
archival_object records in repository SC

But then

Staff Indexer [2017-09-15 04:09:49 -0700] ~~~ Indexed 25 of 212959 
archival_object records in repository SC

Since yesterday it has re-indexed ten times.

The resulting constant re-indexing causes a high load average and slow 
performance for users.

Any suggestions?

Thanks,

Ron

ps.  I also posted this question to 
https://groups.google.com/forum/#!forum/archivesspace.  Sorry if that is 
redundant.
___
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 with collection level display in admin screen

[Blake Carver]

Hi Brent,
Did you do a full reindex when you did the upgrade?
If not, give that a try. We've seen that error once before and rebuilding the 
index cleared it up.
http://archivesspace.github.io/archivesspace/user/re-creating-indexes/


-Blake

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Brent 
Ellingson 
Sent: Friday, September 15, 2017 11:13:04 AM
To: Archivesspace Users Group (archivesspace_users_group@lyralists.lyrasis.org) 
(archivesspace_users_group@lyralists.lyrasis.org)
Subject: Re: [Archivesspace_Users_Group] Error with collection level display
in admin screen

Here is an error log entry that I’m hoping will be more relevant to the root of 
the problem

Started GET "/resources/1540" for 0:0:0:0:0:0:0:1 at 2017-09-15 08:57:57 -0600
Processing by ResourcesController#show as HTML
  Parameters: {"id"=>"1540"}
  Rendered shared/_breadcrumb.html.erb (1.0ms)
  Rendered transfer/_transfer_failures.html.erb (0.0ms)
  Rendered shared/_tree.html.erb (3.0ms)
  Rendered resources/show.html.erb within layouts/application (9.0ms)
  Rendered shared/_browser_support.html.erb (0.0ms)
  Rendered shared/_header_user.html.erb (5.0ms)
  Rendered shared/_header_global.html.erb (6.0ms)
  Rendered site/_branding.html.erb (0.0ms)
  Rendered shared/_advanced_search.html.erb (5.0ms)
  Rendered shared/_header_repository.html.erb (17.0ms)
  Rendered site/_footer.html.erb (0.0ms)
  Rendered shared/_templates.html.erb (3.0ms)
Completed 200 OK in 2033.0ms (Views: 42.0ms)
ri"=>"root", "hash"=>"tree::resource_1540", "id"=>"1540"}
:resource_1540" for 0:0:0:0:0:0:0:1 at 2017-09-15 08:58:00 -0600
Processing by ResourcesController#tree as */*
  Parameters: {"node_uri"=>"root", "hash"=>"tree::resource_1540", "id"=>"1540"}
Completed 200 OK in 860.0ms (Views: 17.0ms)
Started GET "/resources/1540?inline=true_id=1540" for 0:0:0:0:0:0:0:1 
at 2017-09-15 08:58:01 -0600
Processing by ResourcesController#show as */*
  Parameters: {"inline"=>"true", "resource_id"=>"1540", "id"=>"1540"}

ABOUT A MINUTE LATER
This shows up in the logs at the same time as the ‘An error occurred loading 
this form. Not Found’ message shows up on the browser

_dispatch/middleware/debug_exceptions.rb:21:in `call'
  actionpack (3.2.22.2) lib/action_dispatch/middleware/show_exceptions.rb:56:in 
`call'
  railties (3.2.22.2) lib/rails/rack/logger.rb:32:in `call_app'
  railties (3.2.22.2) lib/rails/rack/logger.rb:16:in `call'
  activesupport (3.2.22.2) lib/active_support/tagged_logging.rb:22:in `tagged'
  railties (3.2.22.2) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.22.2) lib/action_dispatch/middleware/request_id.rb:22:in 
`call'
  rack (1.4.7) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.7) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.22.2) 
lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  actionpack (3.2.22.2) lib/action_dispatch/middleware/static.rb:83:in `call'
  rack-cache (1.6.1) lib/rack/cache/context.rb:140:in `forward'
  rack-cache (1.6.1) lib/rack/cache/context.rb:249:in `fetch'
  rack-cache (1.6.1) lib/rack/cache/context.rb:189:in `lookup'
  rack-cache (1.6.1) lib/rack/cache/context.rb:66:in `call!'
  rack-cache (1.6.1) lib/rack/cache/context.rb:51:in `call'
  railties (3.2.22.2) lib/rails/engine.rb:484:in `call'
  railties (3.2.22.2) lib/rails/application.rb:231:in `call'
  
file:/srv/archivesspace-1.5.4-stg/archivesspace/gems/gems/jruby-rack-1.1.20/lib/jruby-rack-1.1.20.jar!/rack/handler/servlet.rb:22:in
 `call'


2.22.2) lib/rails/application.rb:231:in `call'
  
file:/srv/archivesspace-1.5.4-stg/archivesspace/gems/gems/jruby-rack-1.1.20/lib/jruby-rack-1.1.20.jar!/rack/handler/servlet.rb:22:in
 `call'


  Rendered 
/srv/asstg/gems/gems/actionpack-3.2.22.2/lib/action_dispatch/middleware/templates/rescues/routing_error.erb
 within rescues/layout (1.0ms)

Any thoughts?

Regards,
Brent Ellingson

From: Brent Ellingson
Sent: Thursday, September 14, 2017 3:29 PM
To: Archivesspace Users Group (archivesspace_users_group@lyralists.lyrasis.org) 
(archivesspace_users_group@lyralists.lyrasis.org) 

Subject: Error with collection level display in admin screen

Greeting all,

We are running 1.5.4 and have 2 collections that error out when trying to 
access the Collection level data on the admin screen.

The URL is
[HOST]/resources/1540#tree::resource_1540
I’m seeing a HTML 404 error code when this URL is requested via JavaScript
[HOST]/resources/1540?inline=true_id=1540

In the browser below the hierarchy of the collection where the form and content 
usually display all I see is the following
‘An error occurred loading this form.
Not Found’

The Series and Sub-Series links in the hierarchy seem to be working without 
problems.

This is what I believe is the error in the logs that corresponds at least in 
part to the