Version: 20251031
Last Updated: October 31, 2025
- ArchivesSpace Request Fulfillment via Aeon
- Table of Contents
- Overview
- Changelog
- Requirements
- Configuring Plugin Settings
- Per Repository Configuration Options
:aeon_web_url:aeon_return_link_label:aeon_external_system_id:requests_permitted_for_containers_only:request_in_new_tab:hide_request_button:hide_button_for_accessions:aeon_site_code:hide_button_for_access_restriction_types:requestable_archival_record_levels:top_container_mode:disallowed_record_level_message:no_containers_message:restrictions_message:user_defined_fields
- Other Configuration Options
- Example Configuration
- Per Repository Configuration Options
- Aeon Remote Authentication Configurations
- Imported Fields
- OpenURL Mappings
- Custom Mappers
- Configuring the Aeon Request Form Used
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 3.3.1, and requires Aeon Server version 5.2.0 or greater. Future releases of ArchivesSpace may cause changes in the functionality of this plugin.
-
20251031
- Added "mixed mode" support to
:top_container_modesetting - Mixed mode (
:mixed) allows requests for both records with and without top containers - Records with top containers route to the Box-Picker form
- Records without top containers route to the ExternalRequest form
- Mixed mode is now the recommended default for new installations
- Backwards compatible with existing
true/falseconfigurations - Fixed nil handling in find_container_instances to handle nil record_json
- Fixed circular dependency during mapper initialization in mixed mode
- Replaced allow_parent_traversal? call with direct mode check to avoid calling record_has_top_containers? before @container_instances is set
- Prevents undefined method `any?' for nil:NilClass error when accessing records without top containers in mixed mode
- Added "mixed mode" support to
-
20241210
- Added example to demonstrate configuration of :disallowed_record_level_message, :no_containers_message, and :restrictions_message settings.
-
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.dllin the:aeon_web_url - If updating to or past this version, you may need to add
aeon.dllto your settings for:aeon_web_url
-
20180319
- Added the
:request_in_new_tab,:hide_request_button, and:hide_button_for_accessionssettings. 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
titleparameter. - Plugin has been refactored so builtin ArchivesSpace functionality can be used.
- Added the
-
20180524
- Fixed a bug with the
:requests_permitted_for_containers_onlysetting - Added an
:aeon_site_codesetting, 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.erbfile 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_codemapping. 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_levelssetting - 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_fieldssetting
- Added the
-
20190529
- Bug fixes for compatibility with ArchivesSpace v2.6.0 RC1
-
20230302
- Added
:top_container_modesetting to support new Aeon Archival Request form. - Added some additional mapping options.
- Added
-
20230725
- Added
:log_recordssetting to reduce amount of data logged unless logging of full records is explicitly enabled.
- Added
-
20241126
- Fixed a bug that caused a login loop when
:top_container_modeis false. Rather than using action=11&type=200 in this case, the AeonForm is specified as ExternalRequest with a hidden input instead.
- Fixed a bug that caused a login loop when
-
20250617
- Fixed a bug that prevented the plugin from correctly handling the
:requests_permitted_for_containers_onlysetting when:top_container_modeis false.
- Fixed a bug that prevented the plugin from correctly handling the
- Aeon Server 5.2.0 or greater
- ArchivesSpace 3.3.1
Please note that the Aeon OpenURLMapping table must be configured in the Customization Manager before the plugin can be used and/or tested with ArchivesSpace. See the OpenURL Mappings section for more information.
If you are using the Atlas Dual Auth Portal to handle remote authentication in Aeon, please ensure that it is configured to support POST data handling. See the Aeon Remote Authentication Configurations section for more information.
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 reference it in the plugin configuration option in this file.
Please note that after enabling the plugin in the config.rb file, the ArchivesSpace
service will need to be restarted to push the plugin to the ArchivesSpace interface.
In the following example, a reference to the 'aeon-fulfillment' plugin has
been added to the list of enabled plugins after the reference to the default 'local' plugin:
AppConfig[:plugins] = ['local', 'aeon_fulfillment']Next, you will need to add the appropriate settings and values for
each repository that will use the plugin. These settings should be placed directly under
the line of code listing your enabled plugins shown above. 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. Please also ensure that the :aeon_return_link_label setting
is included directly below the :aeon_web_url.
AppConfig[:aeon_fulfillment] = {}
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. Note: The :aeon_site_code setting should be
removed if you are not assigning multiple repositories to separate Aeon site codes
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"If preferred, this plugin configuration can also be formatted using the implicit form of a Ruby hash, with settings for each repository grouped within curly braces and separated one per line. A comma should follow each individual line until the end of the block of settings for the repository is reached, and also after the closing curly brace for each repository until the last repository is reached:
AppConfig[:aeon_fulfillment] = {
"atlas" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace"
},
"test-repo" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace Test Repo"
}
}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 values in the local_access_restriction_type field of the rights_restriction of the accessrestrict note. 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 will log the full content of ArchivesSpace records when set to true. This can be useful for debugging mappings and plugin issues, but should not normally be enabled.
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 controls how the plugin handles requesting based on the presence of top container data. It accepts three values:
-
true- Only top containers associated with the current record are requestable. If no top containers are associated with the current record, then the request button will be replaced by a message (see:no_containers_messagesetting below). When the user clicks the Aeon Request button, they will be taken to the Aeon Box-Picker form to submit their request(s). This is the best option for large institutions where all requestable materials have been fully processed and assigned to top containers. -
false- Allows requesting for all records regardless of whether they have top containers. All requests use the generic Aeon ExternalRequest form. If the current record does not have top containers, the plugin will traverse up the resource tree to find container information from parent records. This is the legacy behavior. -
:mixedor"mixed"- (RECOMMENDED) Adaptive mode that examines each record individually:- If the record has top containers: routes to the Box-Picker form with container data
- If the record has no top containers: routes to the ExternalRequest form with available metadata
- Does not traverse to parent records for container information (only uses containers directly associated with the current record)
- This mode is ideal for institutions with a mix of processed and unprocessed materials
Note: If this setting is true, then :requests_permitted_for_containers_only should also be set to true. The :requests_permitted_for_containers_only setting works independently of this setting and can be used with any mode to control whether records without top containers are requestable.
Default: false (for backwards compatibility; :mixed is recommended for new installations)
Example: Mixed mode configuration (recommended for most institutions)
AppConfig[:aeon_fulfillment] = {
"repo code" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "Back to ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace",
:top_container_mode => :mixed,
:disallowed_record_level_message => "Not requestable",
:restrictions_message => "Access restricted"
}
}Example: Top container only mode (for fully processed collections)
AppConfig[:aeon_fulfillment] = {
"repo code" => {
:aeon_web_url => "https://your.institution.edu/aeon/aeon.dll",
:aeon_return_link_label => "Back to ArchivesSpace",
:aeon_external_system_id => "ArchivesSpace",
:top_container_mode => true,
:requests_permitted_for_containers_only => true,
:no_containers_message => "No requestable containers"
}
}This is the message that will be displayed instead of the Aeon Request button if the current record cannot be requested due to the values listed in the :requestable_archival_record_levels setting. If no value is provided, the default value will be "Not requestable". The message should be kept short (30 characters or less) for best appearance.
This is the message that will be displayed instead of the Aeon Request button if the current record has no associated topcontainers and :top_container_mode is active. If no value is provided, the default value will be "No requestable containers". The message should be kept short (30 characters or less) for best appearance.
This is the message that will be displayed instead of the Aeon Request button if the current record cannot be requested because it has active restrictions matching the values in the :hide_button_for_access_restriction_types setting. If no value is provided, the default value will be "Access Restricted". The message should be kept short (30 characters or less) for best appearance.
Example 1 Specifies messages for :disallowed_records_level_message, :no_containers_message, and :restrictions_message.
AppConfig[:aeon_fulfillment] = {
"repo code" => {
# ...
:top_container_mode => true,
:disallowed_record_level_message => "Not requestable",
:no_containers_message => "No requestable containers",
:restrictions_message => "Access restricted"
}
}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
trueorfalse, indicating that all or none of the fields should be mapped into the HTML form.falseis 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] = ['local', '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. However, please note that some additional configuration is required to enable POST data support for the Dual Auth Portal. If you use the Portal and are experiencing issues with POST data persistence between ArchivesSpace and Aeon, please see the Using an Authentication Portal Landing Page page for information on configuring the Portal to support POST data.
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.
SystemIDReturnLinkURL- 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:8081as 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
ReturnLinkSystemNameSiteidentifierpublish(true/false value)leveltitleurirepo_coderepo_namelanguage- semi-colon (
;) separated string list - contains the content from the
languageelements listed inlang_materials - for accessions, contains the single value in the
languageelement
- semi-colon (
restrictions_apply(true/false value)display_stringcreators- semi-colon (
;) separated string list
- semi-colon (
{date_label}_date- semi-colon (
;) separated string list - contains the content from the
expressions 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_labelenumeration of your ArchivesSpace installation.
- semi-colon (
date_expression- semi-colon (
;) separated string list - contains the combined final_expressions of the single and inclusive dates associated with the record.
- semi-colon (
rights_type- semi-colon (
;) separated string list - contains the combined rights_type values of all rights statements associated with the record.
- semi-colon (
digital_objects- semi-colon (
;) separated string list - contains the IDs of all digital objects associated with the record.
- 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_representativeinstance_last_modified_byinstance_instance_typeinstance_created_byinstance_container_grandchild_indicatorinstance_container_child_indicatorinstance_container_grandchild_typeinstance_container_child_typeinstance_container_last_modified_byinstance_container_created_byinstance_top_container_refinstance_top_container_uriinstance_top_container_long_display_stringinstance_top_container_last_modified_byinstance_top_container_display_stringinstance_top_container_restrictedinstance_top_container_created_byinstance_top_container_indicatorinstance_top_container_barcodeinstance_top_container_typeinstance_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)instance_top_container_location_noteinstance_top_container_location_titleinstance_top_container_location_idinstance_top_container_location_building
In addition to the fields specified above, the following additional fields are specific to requests made for Archival Object records.
accessrestrict- semi-colon (
;) separated string list - contains the content from
accessrestrictsubnotes
- semi-colon (
collection_idcollection_titlecomponent_idphysical_location_note- semi-colon (
;) separated string list - contains the content from
physlocnotes
- semi-colon (
repository_processing_noteuserestrict- semi-colon (
;) separated string list - contains the combined contents of all published userestrict notes associated with the record.
- semi-colon (
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_noteaccess_restrictions_notelanguage- 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_notecollection_idcollection_titleead_idead_locationfinding_aid_titlefinding_aid_subtitlefinding_aid_filing_titlefinding_aid_datefinding_aid_authorfinding_aid_description_rulesresource_finding_aid_description_rulesfinding_aid_languagefinding_aid_sponsorfinding_aid_edition_statementfinding_aid_series_statementfinding_aid_statusfinding_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_1user_defined_boolean_2user_defined_boolean_3user_defined_integer_1user_defined_integer_2user_defined_integer_3user_defined_real_1user_defined_real_2user_defined_real_3user_defined_string_1user_defined_string_2user_defined_string_3user_defined_string_4user_defined_text_1user_defined_text_2user_defined_text_3user_defined_text_4user_defined_text_5user_defined_date_1user_defined_date_2user_defined_date_3user_defined_enum_1user_defined_enum_2user_defined_enum_3user_defined_enum_4
Below is a list of recommended Open URL mappings that should be set in Aeon.
-
The
rfr_idcolumn should exactly match the configured:aeon_external_system_idfor each repository. Multiple repositories can have the same or different System IDs. -
The
AeonFieldNamecolumn should exactly match an Aeon field name. -
Each value in the
OpenURLFieldValuesshould contain a<#replacement-tag>that has a name that matches one of the field names from the Imported Fields section.
The SQL script below can be used to add some basic mappings to the OpenURLMapping table in Aeon. Additional mappings can then be added manually to the table in the Aeon Customization Manager. For more information on configuring this feature Aeon, please visit the Submitting Requests via OpenURL page of our documentation.
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
OpenURLFieldValuescolumn 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.