[Archivesspace_Users_Group] yale accessions plugin & defaults + preferences

[Custer, Mark]

Steve,

Just a quick note to say that at Yale we are indeed using this plugin!  The plugin was developed before the "pre-populate records?" feature was added to ArchivesSpace, so it could definitely stand to be updated (additionally, I don't believe that the "pre-populate records?" feature activates in any way when spawning an accession record to a resource or accession record).  If there's a better way to handle these automatically-assigned identifiers, I'd love to know that, as well.  One thing that we depend on right now, though, is the ability to add and delete new department codes per repository directly within the application, since we use those department codes as part of our accession identifiers.  In any event, since I'm sure that we'll need to revisit some of our plugins for maintenance purposes, it would be great to have any other feedback that you have that would make this plugin more useful for your needs.

Also, I completely agree in your assessment of the user/default settings.  I would love to have the ability to see the current state of defaults that the application is using without having to go the trial-and-error route.  But even more than that, I'd love the ability to customize what displays on the search-results screens just like you can on the browse-results screens.  Along these lines, has anyone done any local usability testing of the staff interface?  If so, it would be great to share that with the community.

Mark



-----Original Message-----
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: Wednesday, December 16, 2015 4:03 PM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] yale accessions plugin & defaults + preferences



Is Yale (or anyone else) actively using the humdol/aspace_yale_accessions plugin ? 



Initially, I forked this plugin and simplified the code somewhat for our use. 

( mainly, eliminated keeping prefixes in the database, as we’re using the Repository org codes: “viu”, “viuh”, “viul” … ) 

However, I’ve discovered that this method is both overly complicated and doesn’t play particularly well with the other methods of setting defaults and “Pre-populate Records?” preference. 



I’ve been testing a different way of doing the same thing: auto generating a set of ids ( id_0, id_1, id_2 ) with repo org-code, year, and sequence #, that uses and works with the existing backend defaults API ( GET /repositories/:repo_id/default_values/:record_type ). This could be a more general method that could work for other defaults, so I’m wondering if anyone has any other use cases for this sort of feature.  



The main remaining issue is how to either override the route for GET /repositories/:repo_id/default_values/:record_type in Sinatra from a plugin, or else how to add a hook in that controller to call a function on that JSON before it’s returned. 

The simpler and cleaner method than monkey patching might require a change to that controller in the base code: if DefaultValues has a post processing method ( possibly added in a plugin ), then call that method on the JSON before

json_response(json)  return. So I’m interested if there is a more general interest in adding this feature. 





Also a comment on the User experience of the admin frontend with these default & preference settings:

The frontend interface follows the internal model, but this makes it pretty awkward to use, as these settings are spread over several different pages, and it’s not immediately obvious what the current state is without checking the settings on ALL of those pages. i.e. there are Global, Repository and User settings and the record defaults aren’t applied unless that “Pre-Populate Records?” is set on yet another page. It would be a lot nicer if these options could be aggregated in some way.  ( If not for setting the state, at least for telling you the current state: i.e. maybe showing you whether the pre-populate is set on the defaults page(s). )  Also, initially I found those settings difficult to find, as I was looking for them from the Create pages rather the the Browse pages, since those defaults are applied in creating a new resource. 





— Steve Majewski / UVA Alderman Library







_______________________________________________
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=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=gvHc8rKxFia5YUWG2-ikuOAEESF4PcqVdyK6h-Hps_E&s=4mDDSeT77uKRoQ9sjEJ1qZvnpAKVgGQ97njOtlQSLkM&e=