Impact of ArchivesSpace PUI Inheritance on Imported Fields

Print Friendly and PDF Follow

This article relates to the relationship between the Aeon Request Fulfillment Plugin and the ArchivesSpace PUI display feature inheritance.

Per the documentation, the Aeon Fulfillment plugin builds a form that is sent to Aeon through the external requests endpoint of the Aeon Web interface. The fields in this form can be mapped to Aeon via OpenURLMapping. This article discusses how and when that functionality is subject to the behavior of inheritance, an ArchivesSpace display feature for the PUI.

The Basics of Inheritance in ArchivesSpace

If inheritance is a completely new topic for you, please consider watching our one-hour webinar titled Know Thy Config: Inheritance, which features a deep-dive into the feature and demonstrations of inheritance in action.

Inheritance in ArchivesSpace is a configurable display option for the Public User Interface that controls when and if certain fields inherit, or in other words, whether certain fields display at levels other than the level on which that information actually originates.

The inclusion of inheritance functionality in ArchivesSpace reflects the archival principles in ISAD(G) Section 2.4: Non-Repetition of Information. Following that principle, information inherits from higher in the hierarchy to lower in the hierarchy -- for example, from the collection-level to the series-level -- and not the opposite. If there is already information on lower levels, inheritance will not inherit that same information from above; instead, the information will display on the level on which it originates and below.

All versions of ArchivesSpace after v 2.1.0 come with inheritance already configured by default. Even if you or your service provider have never altered your inheritance settings for ArchivesSpace, inheritance is expected to be on with the default settings.

Inheritance is controlled in the ArchivesSpace with the following configuration:


Follow this link to view the ArchivesSpace inheritance configuration defaults as of v3.3.1; though that link is for 3.3.1, these settings have not changed since they were introduced and are not expected to change in the future.

Impact of Inheritance on Imported Fields and OpenURLMapping

Inheritance is only a display feature and only applies to the PUI. However, since the Aeon Fulfillment Plugin is drawing on data available in the PUI data model, this means inheritance functionality and settings can impact whether and when data imports to Aeon via the plugin. The Aeon Fulfillment Plugin was developed against the default, out-of-the-box inheritance configurations for ArchivesSpace; if a site has changed inheritance for their instance of ArchivesSpace, the field importing will be affected in the same way.

The goal of this article is to explore and demonstrate how those configurations can impact the data being delivered to Aeon. That is best served with examples.

Example: The Access Restriction Note (inherits by default)

In the following example, there is an access restriction note only on the collection-level. With default inheritance settings on, this note will inherit to any level below the collection that doesn't have its own access restriction note.

The following screenshot shows the collection-level note appearing at the file-level in the PUI:

This inherited information will pass to Aeon via OpenURL Mappings (if configured to do so), meaning Aeon will respect and display inherited fields as well as fields that originated on the record itself.

If top container mode is enabled, that same note passes to the Archival Request box picker form (ArchivalRequest.html). Note that the same note appears in the box picker form below:

Top container mode is not required for this information to pass to Aeon via OpenURL Mappings.

In the next example, the same file-level description now has its own access restriction note. This means the collection note will no longer inherit and the file-level note will pass to Aeon instead. The following two screenshots demonstrate this change in behavior:

On the ArchivesSpace PUI:

In the Aeon box picker form:

This demonstrates how default inheritance settings can have an effect on what data is passed to Aeon.

Example: The Use Restriction Note (does not inherit by default)

Unlike the Access Restriction Note, the Use Restriction Note is not configured to inherit unless a site decides to add this to their inheritance configurations in ArchivesSpace. The Use Restriction Note maps to userestrict in the Imported Fields mapping.

You can see an example of this note below in the PUI:

The following snippet would need to be added to AppConfig[:record_inheritance] in the ArchivesSpace configuration file in order for the Use Restriction Note to inherit:

:property => 'notes',
:inherit_if => proc {|json| {|j| j['type'] == 'userestrict'} },
:inherit_directly => true
Sites hosting ArchivesSpace with Atlas Systems may request changes to inheritance configurations by submitting a support request. Note that changing inheritance requires a restart and one-time re-indexing of the PUI.
We highly recommend our one-hour webinar titled Know Thy Config: Inheritance when considering inheritance changes.

Exception: Local Access Restrictions

Inheritance settings do not affect the Local Access Restriction flags, which automatically inherit to top containers at or below the level where the restriction exists. These restrictions will always be present (unless they are expired) and are unaffected by inheritance configurations.

Please note that because all top containers below the restriction will be flagged, use of these flags should be limited to Access Restrictions at or above the level where the restrictions actually exist.

Sites can configure which local access restriction types should block requests by configuring the following for the Aeon Fulfillment Plugin:


See our related article Impact of ArchivesSpace Local Access Restrictions on Requesting Top Containers.

Default Inheritance Configurations and their Plugin Mappings

The following crosswalk maps the Default ArchivesSpace Inheritance Configurations to mappings (when they exist) in the Aeon Fulfillment Plugin as of the date of this article. It was created by comparing the default ArchivesSpace config.rb to the mappings available in the plugin documentation.

The values in the mapping column below will be affected by inheritance as described in this article. Note that this table is only mapping the default inheritance configurations; any inheritance configurations that are added to ArchivesSpace will likewise affect the mapping in the fulfillment plugin (if a mapping exists).

Default ArchivesSpace Inheritance Configuration
Aeon Fulfillment Plugin Mapping
:property => 'title' title
:property => 'component_id' component_id
:property => 'lang_materials' language
:property => 'dates'



:property => 'extents' [not mapped]
:property => 'linked_agents',
:inherit_if => proc {|json| {|j| j['role'] == 'creator'} }
:property => 'notes',
:inherit_if => proc {|json| {|j| j['type'] == 'accessrestrict'} }
:property => 'notes',
:inherit_if => proc {|json| {|j| j['type'] == 'scopecontent'} }
[not mapped]
:property => 'notes',
:inherit_if => proc {|json| {|j| j['type'] == 'langmaterial'} }
[not mapped]


If this article didn’t resolve your issue, please contact Atlas Support for assistance:

Contact Support