This is an ArchivesSpace plugin that implements Yale's public requesting workflows.
Yale uses Aeon to manage requests. This plugin maps ArchivesSpace records to Aeon request structures and sends the requests to Aeon when the public user clicks the request button.
This is a fork from the original Atlas developed plugin 'ArchivesSpace-Aeon-Fulfillment-Plugin'. Yale has decided to adopt this version, so now development will continue here. To that end we have merged the 'yale_aeon_mappings' plugin into this one to simplify future development.
In addition to the configuration options described below, this version introduces the following.
:requests_permitted_for_born_digital
- boolean in repo config (default false)
Set to true to enable repository requests for born-digital archival objects (with a local access restriction type of BornDigital
).
Example
AppConfig[:aeon_fulfillment] = {
"repo_code" => {
...
:requests_permitted_for_born_digital => true,
...
},
:disable_digital_copy_request_for_access_restriction_types
- array of strings (default empty) -- Include any local access restriction types that will disable the digital copy request option for a particular record.
:disable_reading_room_request_for_access_restriction_types
- array of strings (default empty) -- Include any local access restriction types that will disable the reading room request option for a particular record.
AppConfig[:aeon_fulfillment_debug]
- boolean (default false)
Set to true to enable detailed debugging information in the logs
This plugin can be used in conjunction with the Aeon Client add-on https://github.com/hudmol/YaleAeonSpace and provides an API endpoint from which the add-on is able to search ArchivesSpace and then populate the Aeon RequestForm for a particular container or BornDigital item.
AppConfig[:aeon_client_max_results] = 1000
Default: 1000. This is the
max number of results returned from the API to the Aeon client.
AppConfig[:aeon_client_repo_codes] = ['myrepo']
Default: All
repositories are searched. When present, the API will only return
results from the repositories listed.
This new API requires an authenticated session with the
view_all_records
permission. If you would like this plugin to bootstrap
this user account for you, provide the username and password with the
following configuration (restart the application for changes to take
effect):
AppConfig[:aeon_client_username] = 'aeonclient'
AppConfig[:aeon_client_password] = 'pw'
The YaleAeonSpace
add-on provides a single input field which when actioned sends the query string to this plugin via a new API endpoint /plugins/yale_as_requests/search?q=YOUR_QUERY_STRING
. This endpoint returns a result set of container and BornDigital items which are mapped into Aeon Client table rows. This row data also contains a mapped Aeon request ready for the client to consume.
The search logic is as follows (q
is the incoming query string):
- Check if
q
is a call number i.e. does a resource identifier exactly match this value.- Yes! We are now a Call Number search!
- No. Just a Normal search :(
From q
we now have a matching resource. A Call Number search will return any containers associated with this resource or its children and include any BornDigital items in the hierarchy.
Find containers where:
q
matches the barcode or- the top container display string contains
q
(where applicable the container display string includes the type, indicator, series label and barcode).
Find archival objects where:
q
matches the title orq
matches the component id orq
matches the ref id orq
matches the URI
For any matching archival objects we return a row entry for each linked container. If the archival object is a BornDigital item, then the archival object itself is mapped and returned as a result row.
The remainder of this README is from the original plugin. It remains valid and useful, though some of the naming etc may have changed.
- ArchivesSpace Request Fulfillment via Aeon
This plugin adds a new request button to archival objects that allows researchers to place Aeon requests for archival objects discovered via the ArchivesSpace Public User Interface.
The functionality provided by this plugin is meant to replace the existing
Public UI request action functionality for archival objects. As such, it is
recommended that the built in functionality be disabled by setting
AppConfig[:pui_page_actions_request] = false
or by removing
:archival_object
from your AppConfig[:pui_requests_permitted_for_types]
setting. The latter will allow you to use Aeon to fulfill archival_object
requests, while still allowing other object types to be requested via the
default email functionality. By using the 'per repository' configuration
options for the built in PUI requesting functionality, it is also possible to
configure some repositories to continue using the built in PUI requesting
feature for archival objects while allowing other repositories to use Aeon.
This plugin has been tested on ArchivesSpace version 2.2.0. Future releases of ArchivesSpace may cause changes in the functionality of this plugin.
- 20170809
- Initial release of this ArchivesSpace plugin
- Added support for sending requests for Archival Objects to Aeon
- 20171110
- Added readme to include configuration resources
- Removed an unused control
- 20171204
- Changes to readme and configuration resources
- Bug fixes
- 20180111
- Moved core functionality out of the
.erb
- Added support for sending requests for Accessions to Aeon
- Bug fixes
- Moved core functionality out of the
- 20180222
- Removed explicit references to aeon.dll from the ruby partial
- This change was made to support Aeon installations that don't specify an
explicit
aeon.dll
in the:aeon_web_url
- If updating to or past this version, you may need to add
aeon.dll
to your settings for:aeon_web_url
- 20180319
- Added the
:request_in_new_tab
,:hide_request_button
, and:hide_button_for_accessions
settings. All are optional and default to false. - Fixed a bug where only the first container would be included in the request.
- Markup is now stripped from the
title
parameter. - Plugin has been refactored so builtin ArchivesSpace functionality can be used.
- Added the
- 20180524
- Fixed a bug with the
:requests_permitted_for_containers_only
setting - Added an
:aeon_site_code
setting, allowing sites to specify the Aeon site code that should be put into the Site field of the Aeon Transaction record. - Added a locale to the en.yml that allows sites to configure the icon on
the Aeon request button without editing the
.html.erb
file directly. Please check https://fontawesome.com/ for the list of available icons.
- Fixed a bug with the
- 20180531
- Additions
- Added support for custom record mappers.
- Added support for specifying record types to be specified from the config.
- Added support for hiding the button for records that have listed access restriction types.
- Added support for positioning the Aeon request button relative to the other page actions.
- Improvements
- Renamed the mappers to include Aeon in the name for a bit of name safety.
- Replaced the switch in the erb that finds the appropriate mapper for
a record with a call to a class method
#mapper_for(record)
on the base record mapper class. - Changed the operation of the
aeon_site_code
mapping. No longer need to specify a mapping for the Aeon site code in the OpenURLMapping table. The Aeon DLL will automatically route the provided Site code directly into the Transaction record. - Now uses a method provided by ArchivesSpace to add the Aeon request button.
- Now shows the button enabled for Accessions even if they don't have containers, in cases where requests are only permitted for containers as well as Accessions.
- Improvements to checking to see if the current record is/has a container.
- Additions
- 20180726
- Fixed a bug with imported instance data.
- 20190110
- Added support for requesting Resource records.
- Added the
:requestable_archival_record_levels
setting - Added functionality to pull instance information from records that exist higher in the resource tree, if the current record does not have any top container instance information.
- Added hover text to the "Aeon Request" button when it is disabled. This text is accessible through screen readers.
- Changed log statements to use the default Rails logger
- 20190111
- The plugin now removes all HTML tags from form values
- 20190115
- Added the
:user_defined_fields
setting
- Added the
- 20190529
- Bug fixes for compatibility with ArchivesSpace v2.6.0 RC1
In order to configure this plugin, you will need to modify the
config/config.rb
file of your ArchivesSpace installation. To enable the
plugin, you will need to add the following to the configuration file.
AppConfig[:plugins] << 'aeon_fulfillment'
AppConfig[:aeon_fulfillment] = {}
Next, you will need to add the appropriate settings appropriate values for
each repository that will use the plugin. In the sample below, replace
{repo_code}
with the repository code for each repository. The repo_code is
also known as the repository's short name. The repo_code must be written using
lower-case.
AppConfig[:aeon_fulfillment]['{repo_code}'] = {}
AppConfig[:aeon_fulfillment]['{repo_code}'][:aeon_web_url] = "{Your aeon web url}"
AppConfig[:aeon_fulfillment]['{repo_code}'][:aeon_return_link_label] = "{The text for the return link from Aeon}"
For example, to configure the plugin for a repository that has the short name
"ATLAS", add the following to config.rb
.
AppConfig[:plugins] << 'aeon_fulfillment'
AppConfig[:aeon_fulfillment] = {}
AppConfig[:aeon_fulfillment]['atlas'] = {}
AppConfig[:aeon_fulfillment]['atlas'][:aeon_web_url] = "https://your.institution.edu/aeon/aeon.dll"
AppConfig[:aeon_fulfillment]['atlas'][:aeon_return_link_label] = "ArchivesSpace"
AppConfig[:aeon_fulfillment]['atlas'][:aeon_site_code] = "AEON"
This plugin configuration can also be formatted using the implicit form of a Ruby hash.
AppConfig[:plugins] << 'aeon_fulfillment'
AppConfig[:aeon_fulfillment] = {
"atlas" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_external_system_id => "ArchivesSpace"
},
"test-repo" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_site_code => "TEST",
:aeon_external_system_id => "ArchivesSpace Test Tepo"
}
}
Required. This setting specifies the web url that points to an Aeon
installation. The plugin will send requests to this url, after adding the
external requests endpoint (?action=11&type=200
) to the end. If you are using
the Atlas Dual Auth Portal, this setting should point to that URL instead
(https://dualauthurl.institution.edu/login/").
Required. This setting specifies the text that will display on the button
that takes users back to ArchivesSpace. Setting either AppConfig[:public_proxy_url]
or AppConfig[:public_url]
in config/config.rb
will influence the link
associated with this label. See the ReturnLinkURL
field below.
Required. This setting specifies the System ID, which is used by Aeon to determine which mapping rules to use from its OpenURLMapping table. Each repository configuration can have their own System ID or they can have a duplicate System ID.
This settings specifies whether requests are limited to resources with top
containers only. The default for this setting is false
.
This setting allows the Aeon request to appear in a different tab, when set to
true
. Defaults to false
.
This setting allows the request button to be hidden for the repository, when set
to true
. The button is hidden completely rather than shown disabled. Defaults
to false
.
This setting allows the request button to be hidden for accessions, when set to
true
. Defaults to false
.
This setting specifies the Aeon site code for a repository. If this setting is not specified in the settings for the repository, no Aeon site code will be sent.
This setting allows the request button to be hidden for any records that have any of the listed local access restriction types. The value of this config item should be an array of restriction types, for example:
:hide_button_for_access_restriction_types => ['RestrictedSpecColl']
By default, no restriction types are hidden.
This setting allows sites to restrict the types of Resources and Archival Objects that are requestable, using the "level" property of the record.
- The setting accepts a few different configurations, specifying either a "whitelist" or a "blacklist" of levels that should either have requesting enabled, or disabled.
- The values that are specified in this list must be entries in the Archival
Record Level (
archival_record_level
) controlled value list. This list can be accessed in the Staff interface through http://archivesspace-staff.yourinstitution.edu/enumerations?id=32. The values specified in this setting must match the "Value" column of the enumeration. The "Translation" column of the enumeration CANNOT be used.
Example 1: Specifies a whitelist. Under this configuration, only Resources and Archival Objects that have a level of either "item" or "file" will be requestable.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:requestable_archival_record_levels => ["item", "file"]
}
}
Example 2: Specifies a whitelist. Under this configuration, only Resources and Archival Objects that have a level of either "item" or "file" will be requestable. This configuration functions identically to the example demonstrated in Example 1.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:requestable_archival_record_levels => {
:list_type => :whitelist,
:values => ["item", "file"]
}
}
}
Example 3: Specifies a blacklist. Under this configuration, Resources and Archival Objects that have a level of either "Collection", "Series", "Sub-Series", "Record Group", or "Sub-Group" cannot be requested through this plugin.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:requestable_archival_record_levels => {
:list_type => :blacklist,
:values => ["collection", "series", "subseries", "recordgrp", "subgrp"]
}
}
}
This setting allows sites to specify which user defined fields are imported. This setting applies to all records that use user defined fields. By default, no user defined fields are pulled from the record into the HTML form. Any fields that are imported will be labelled according to the section on user defined fields below. The setting accepts a few different configurations:
- You can specify the setting as either
true
orfalse
, indicating that all or none of the fields should be mapped into the HTML form.false
is the default for this setting. - You can specify the setting as either a "whitelist" or a "blacklist" of user defined fields that should or should not be mapped.
- The values that are specified in this list MUST be the names of the fields as they appear in the database and in the user defined schema. The localizations/translations for these fields CANNOT be used.
Example 1: Specifies that all fields from the User Defined Fields should be
mapped into the HTML form. If false
is used in place of true, none of the
fields will be imported. false
is the default value.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:user_defined_fields => true
}
}
Example 2: Specifies a whitelist, variation 1. Under this configuration, only the 3 user defined fields that are listed will be imported into the HTML form.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:user_defined_fields => ["text_1", "string_1", "real_2"]
}
}
Example 3: Specifies a whitelist, variation 2. This configuration is identical to Example 2.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:user_defined_fields => {
:list_type => :whitelist,
:values => ["text_1", "string_1", "real_2"]
}
}
}
Example 4: Specifies a blacklist. Under this configuration, all of the user defined fields that are not specified in this list will be imported, except for the ones that are listed.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:user_defined_fields => {
:list_type => :blacklist,
:values => [
"text_1", "text_2", "text_3",
"string_1", "string_2",
"boolean_1", "boolean_2", "boolean_3"
]
}
}
}
The following configuration options apply globally, rather than for a particular repository.
This setting takes an array of record types. It allows this plugin to handle additional record types via custom mappers (see below).
This setting supports the positioning of the request button relative to the
other buttons appearing on a page. By default the button will appear to the
right of all built in buttons and to the left of any plugin buttons loaded
after it. Setting this to 0
will cause the request button to appear to the
left of the built in buttons.
AppConfig[:plugins] << "aeon_fulfillment"
AppConfig[:aeon_fulfillment_record_types] = ['accession', 'archival_object', 'resource']
AppConfig[:aeon_fulfillment_button_position] = 2
AppConfig[:aeon_fulfillment] = {
"special research collections" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "Back to ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace",
:aeon_site_code => "SPECCOLL",
:requests_permitted_for_containers_only => true
},
"test special collections" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "Back to ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace Test",
:aeon_site_code => "TEST",
:requests_permitted_for_containers_only => false
}
}
This plugin is designed to send as much data from ArchivesSpace as possible to allow users to easily map fields on the Aeon side of the integration. As such, it uses POST data rather than GET parameters so that data does not get truncated. This can be problematic for some remote authentication systems. If you are using the Atlas Dual Auth Portal, it already has functionality to resolve this issue by persisting POST data during the remote authentication process so you can simply configure this plugin to send requests to it instead of directly to Aeon. If you are not using the Atlas Dual Auth Portal with your remote authentication configuration or are having difficulty getting it configured correctly, please contact Atlas Support.
This plugin builds a form that is sent to Aeon through the external requests
(?action=11&type=200
) endpoint of the Aeon Web interface. Below are the
names of the fields as they will appear in the request.
These fields are imported from both Archival Object records and Accession records.
SystemID
ReturnLinkURL
- The return link is populated using either the
AppConfig[:public_proxy_url]
or theAppConfig[:public_url]
, depending on which has a value. If both are set, thenAppConfig[:public_proxy_url]
takes precedence. If neither is specified inconfig/config.rb
, then the ArchivesSpace default value (http://localhost:8081
as of this writing) will be used. The URI of the requested record is suffixed to this value to form the complete return link.
- The return link is populated using either the
ReturnLinkSystemName
Site
identifier
publish
(true/false value)level
title
uri
collection_id
collection_title
repo_code
repo_name
language
restrictions_apply
(true/false value)display_string
creators
- semi-colon (
;
) separated string list
- semi-colon (
accessrestrict
- semi-colon (
;
) separated string list - contains the content from
accessrestrict
subnotes
- semi-colon (
physical_location_note
- semi-colon (
;
) separated string list - contains the content from
physloc
notes
- semi-colon (
{date_label}_date
- semi-colon (
;
) separated string list - contains the content from the
expression
s of the record's related dates - The plugin will group all of the related dates of each record based on
the date's label. For each distinct date label of the dates that are
linked to the record, the request to Aeon will contain a distinct date
parameter. Some examples of what to expect for the name of this field
include
creation_date
,event_date
, andother_date
. The full list of values that could appear in place of the{date_label}
placeholder is controlled by thedate_label
enumeration of your ArchivesSpace installation.
- semi-colon (
The following fields are common to both Accession records and Archival Object records, but are based on the number of instances associated with the record. The number of requests sent to Aeon is equal to the number of instances associated with the record. If there are no instances, only one request will be sent to Aeon. All of these fields are dependant on the number of instances, and the values of each may differ from instance to instance.
instance_is_representative
instance_last_modified_by
instance_instance_type
instance_created_by
instance_container_grandchild_indicator
instance_container_child_indicator
instance_container_grandchild_type
instance_container_child_type
instance_container_last_modified_by
instance_container_created_by
instance_top_container_ref
instance_top_container_uri
instance_top_container_long_display_string
instance_top_container_last_modified_by
instance_top_container_display_string
instance_top_container_restricted
instance_top_container_created_by
instance_top_container_indicator
instance_top_container_barcode
instance_top_container_type
instance_top_container_collection_identifier
(semi-colon (;
) separated string list)instance_top_container_collection_display_string
(semi-colon (;
) separated string list)instance_top_container_series_identifer
(semi-colon (;
) separated string list)instance_top_container_series_display_string
(semi-colon (;
) separated string list)
In addition to the fields specified above, the following additional fields are specific to requests made for Archival Object records.
repository_processing_note
component_id
In addition to the fields specified in the list of common fields, the following additional fields are specific to requests made for Accession records.
use_restrictions_note
access_restrictions_note
language
- This field is also present on most Archival Object requests, but it is mapped from a different location for Accession requests.
accession_id
In addition to the fields specified in the list of common fields, the following additional fields are specific to requests made for Resource records.
repository_processing_note
collection_id
collection_title
ead_id
ead_location
finding_aid_title
finding_aid_subtitle
finding_aid_filing_title
finding_aid_date
finding_aid_author
finding_aid_description_rules
resource_finding_aid_description_rules
finding_aid_language
finding_aid_sponsor
finding_aid_edition_statement
finding_aid_series_statement
finding_aid_status
finding_aid_note
You can use the :user_defined_fields
setting
to configure which user defined fields are imported. These fields are imported
with the "user_defined_"
prepended to the name of the field. Below shows the
formatting of all of the user defined fields, as they would exist in the HTML
form.
user_defined_boolean_1
user_defined_boolean_2
user_defined_boolean_3
user_defined_integer_1
user_defined_integer_2
user_defined_integer_3
user_defined_real_1
user_defined_real_2
user_defined_real_3
user_defined_string_1
user_defined_string_2
user_defined_string_3
user_defined_string_4
user_defined_text_1
user_defined_text_2
user_defined_text_3
user_defined_text_4
user_defined_text_5
user_defined_date_1
user_defined_date_2
user_defined_date_3
user_defined_enum_1
user_defined_enum_2
user_defined_enum_3
user_defined_enum_4
Below is a list of recommended Open URL mappings that should be set in Aeon.
-
The
rfr_id
column should exactly match the configured:aeon_external_system_id
for each repository. Multiple repositories can have the same or different System IDs. -
The
AeonFieldName
column should exactly match an Aeon field name. -
Each value in the
OpenURLFieldValues
should contain a<#replacement-tag>
that has a name that matches one of the field names from the Imported Fields section.
For more information on configuring Aeon for this system, please visit the Submitting Requests via OpenURL page of our documentation at https://prometheus.atlas-sys.com.
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'ItemAuthor', '<#creators>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'ItemDate', '<#creation_date>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'ItemTitle', '<#title>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'Location', '<#instance_top_container_long_display_string>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'ItemNumber', '<#instance_top_container_barcode>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'ItemISxN', '<#physical_location_note>', 'NULL');
INSERT INTO OpenURLMapping (URL_Ver, rfr_id, AeonAction, AeonFieldName, OpenURLFieldValues, AeonValue) VALUES ('Default', 'ArchivesSpace', 'Replace', 'CallNumber', '<#physical_location_note>|<#collection_id>', 'NULL');
The plugin provides default mappers for Accession and ArchivalObject records. To support other record types, specify the list of supported record type in configuration like this:
AppConfig[:aeon_fulfillment_record_types] = ['archival_object', 'accession', 'custom_record_type']
It is possible to override the default mappers by providing a custom mapper class. Mapper classes register to handle record types by calling the class method #register_for_record_type(type), like this:
register_for_record_type(Accession)
The custom mapping class should inherit from one of the provided mapper classes and then implement whatever custom mappings are required by overriding the relevant methods. (See the default mappers for examples, as they override behavior from the base AeonRecordMapper class)
The custom mapping class can be loaded from another plugin provided it is listed after this plugin in the array of plugins in the configuration.
It is possible to control the Aeon request form that fulfillment requests use by adding an entry to
the OpenURLMapping table for the DocumentType
parameter. The new OpenURLMapping entry should
resemble (Default, ArchivesSpace, Replace, DocumentType, [SomeDocumentType])
. For example, using
"Manuscript" in place of [SomeDocumentType]
causes requests to use the GenericRequestManuscript
form.
There is some complexity to controlling which form is used:
-
Aeon Transaction fields will populated if (a) there is an entry in OpenURLMapping for the Aeon Transaction field and (b) if the result of evaluating tag strings from the
OpenURLFieldValues
column of the OpenURLMapping table against the OpenUrl request from ArchivesSpace results in a non-empty value. Aeon Transaction fields can also be populated directly, if there is a direct match between one of the parameters of the OpenUrl request and a field in the Aeon Transaction table. -
If DocumentType and RequestType are both not populated, or if their values do not make sense to Aeon, then the Aeon Transaction will use the DefaultRequest form.
-
If DocumentType is not populated, or if it's populated as "Default", and RequestType is populated as "Copy", then the Aeon Transaction will use the PhotoduplicationRequest form.
-
If DocumentType is not "Default", then the name of the form that the Aeon Transaction will use will be "GenericRequest", concatenated with the value stored in DocumentType parameter on the Aeon Transaction.