Impact of ArchivesSpace Local Access Restrictions on Requesting Top Containers

This article relates to the relationship between the Aeon Request Fulfillment Plugin and ArchivesSpace Local Access Restriction Types, an optional setting in the broader functionality of Active Restrictions in ArchivesSpace.

This article applies only when the following configuration is in place for the plugin:

:hide_button_for_access_restriction_types

An example of that configuration is as follows:

:hide_button_for_access_restriction_types = ['RestrictedSpecColl', 'RestrictedFragileSpecColl']

The configuration above means that the plugin will prevent requests when the Local Access Restriction Type "RestrictedSpecColl" OR 'RestrictedFragileSpecColl' are selected and active in ArchivesSpace.

This article discusses this functionality and troubleshooting.

The Basics of Active Restrictions in ArchivesSpace

Active Restrictions (also referred to as machine-actionable restrictions) is container management functionality native to ArchivesSpace that automatically applies restrictions flags to top containers. It was designed by the Yale Archival Management Systems Committee and developed by Hudson-Molonglo. It was introduced in v1.5.0 in July of 2016. 

Active Restrictions are flags that appear on any top container linked to any component at or below a level where an active restriction has been put in place. Notably, these flags live on the top container records themselves (as opposed to the Resource or Archival Object) and persist across collections.

Types of Active Restrictions

Two types of active restrictions are possible in ArchivesSpace, but only one allows for the type selection respected by the Aeon Fulfillment Plugin.

The two possible Active Restriction types in ArchivesSpace are:

1. Conditions Governing Access
   • This type of Active Restriction includes the optional Local Access Restriction Type that triggers the plugin behavior (when configured).
2. Conditions Governing Use
   • Though this note is available for OpenURLMapping, the presence of an active Conditions Governing Use restriction does not relate to any behavior in the Aeon Fulfillment Plugin.

What triggers an Active Restriction in ArchivesSpace?

An Active Restriction flag is triggered when either:

1. A Restriction Begin or Restriction End date is provided on either a Conditions Governing Access or Conditions Governing Use subrecord, or
2. A Local Access Restriction Type is added to the Conditions Governing Access subrecord (whether or not restriction dates are present)
   
   • Use of the optional Local Access Restriction Type is what triggers the plugin behavior (when configured).

Note that Active Restrictions are not triggered by the presence of Conditions Governing Access or Use note, only by the presence of either restriction dates and/or a Local Access Restriction Type.

Whether or not an Active Restriction is active is based on the dates provided in the Restriction Begin and Restriction End fields:

• If no dates are provided, the restriction is active indefinitely.
• If only a Restriction Begin date is provided, the restriction is active after the begin date and then indefinitely.
• If only a Restriction End date is provided, the restriction is active until the end date occurs.
• If both a Restriction Begin and Restriction End date are provided, the restriction is active in the period after the begin date and until the end date.

When a restriction expires, the information remains in the subrecord, but the Active Restriction flag is removed from the top container record (i.e. it is no longer active). Once the flag disappears, the plugin will allow a request for an expired Local Access Restriction.

Types of Local Access Restrictions

The Conditions Governing Access subrecord contains the optional Local Access Restriction Type that triggers the plugin behavior (when configured).

There are five default Local Access Restriction Types in ArchivesSpace. These defaults originated when this functionality was still plugin (prior to v1.5.0) as designed for Yale University. The following are the five default values as they display in the staff interface versus their actual values.

This list is viewable and can be customized from within the Staff Interface by navigating to the System menu, selecting Manage Control Value Lists and then selecting Local Access Restriction Type (restriction_type).

A site can configure the Aeon Fulfillment Plugin to block requests for particular values. First check to see if your instance of ArchivesSpace has customized values, and then determine which should block requests. The text listed in the Value column in the Local Access Restriction Type (restriction_type) list are the values used when configuring the plugin. Only the values listed in the plugin will be blocked.

Impact of Local Access Restrictions on Requesting via the Plugin

When configured, the Aeon Fulfillment Plugin will prevent requests for any top containers that have the Local Access Restriction Type corresponding to the type(s) listed in the configuration.

Preventing container requesting is accomplished two ways depending on whether Top Container mode is enabled:

1. In all cases the Request button is removed from the PUI on records where an Active Restriction is present and is replaced with a configurable message.
2. When Top Container Mode is on, restricted boxes are unavailable to select in the box picker form and a message explains that the container is restricted. Note that seeing a restricted container in the box picker form is expected to be relatively rare; this only occurs when a patron requests a top container from an unrestricted collection but the same container is flagged as restricted in a different collection. This is typical for small collections that share a single container.

If there is more than one Local Access Restriction Type on a single top container, the plugin is designed to respect the presence of any blocking value listed in the configuration.

This is the default button when requesting is allowed:

This message appears when the request is not allowed:

Requesting is prevented and a configurable message appears in the box picker form when Top Container Mode is on and a restricted container passes to the form:

Configuring the Aeon Fulfillment Plugin

As stated in the introduction, this article applies only in the cases when the following configuration is in place for the plugin:

:hide_button_for_access_restriction_types

Such as:

:hide_button_for_access_restriction_types = ['RestrictedSpecColl', 'RestrictedFragileSpecColl']

The plugin will hide the request button if the record has any Local Access Restriction Type that appears in the configuration list above, OR if all of the top containers associated with the record have Local Access Restriction Types that appear in the configuration list above.

The message that appears for a restricted container is modified with the following configuration:

:restrictions_message

Troubleshooting and FAQ

Please read below for troubleshooting tips and frequently asked questions.

Troubleshooting: More containers are restricted now than in the past

Probable Cause: Changes to the plugin in v20230302 made restriction handling stricter

Please note that this behavior changed in the version of the plugin (v20230302) released in conjunction with Aeon v5.2. Prior to this version, the plugin would hide the request button if the record (Resource or Archival Object) had a Local Access Restriction Type that appears in the configuration list but without the additional consideration for Active Restriction top container flags. The current behavior is more secure and conforms to the intentional design of the Active Restrictions functionality.

Troubleshooting: Too many top containers are restricted

Probable Cause: Local Access Restriction is too high in the hierarchy

Active Restrictions are flags that appear on any top container linked to any component at or below a level where an active restriction has been put in place. A probable cause of too many restricted top containers is that a Local Access Restriction Type (an optional part of an Active Restriction) appears too high in the hierarchy, thus restricting more containers than intended.

The following graphics demonstrate that restrictions at high levels restrict many containers.

Local Access Restriction at the Collection-Level

A Local Access Restriction at the collection-level will restrict every container in the collection.

Local Access Restriction at the Series-Level

A Local Access Restriction at the series-level will restrict every container in the series. including children of that series, but not the containers in a sibling component. This is more granular than restrictions at the collection level.

Local Access Restriction at the Subseries-Level

A Local Access Restriction at the subseries-level will restrict every container in the subseries, including children of that subseries, but not the containers in a sibling component.

Local Access Restriction at the File-Level

A Local Access Restriction at the file-level will restrict only the container(s) attached to that component but not the containers in sibling components.

Troubleshooting: A container is restricted, but there is no Local Access Restriction anywhere in the collection

Probable Cause: A Local Access Restriction has been applied to this container in another collection

Since Active Restriction flags live on the top container record itself, Local Access Restrictions persist across collections. If a container is marked as restricted in a collection where there are no Local Access Restriction Types, this implies that the container has been marked as restricted in another collection that is not the collection where the request is originating.

What about the restrictions checkbox?

One potential source of confusion in ArchivesSpace is that there are multiple ways to indicate that something has been restricted. The Restrictions Apply? checkbox is present in Accession, Resource, and Archival Object records and, significantly, is where legacy restriction values (such as those in Archon and Archivists' Toolkit) migrated to.

It is anticipated that more institutions will have the checkbox values than have Active Restrictions values only because the checkbox had legacy mapping (and Active Restrictions did not).

Though the "Restriction Apply?" checkbox is available for OpenURLMapping, its value (checked or unchecked) does not relate to any behavior in the Aeon Fulfillment Plugin.