ArchivesSpace public UI plugin available to test

The latest version of our ArchivesSpace/Aeon plugin is available for download here: Please be sure to read the readme file in its entirety first. 

For reference, this plugin works only with the ArchivesSpace Public Interface. It is compatible with ArchivesSpace version 2.1.0 and higher. You will need to coordinate with your local IT or whoever is hosting your instance of ArchivesSpace to have this installed. We will be happy to help you configure the plugin for testing after that. We recommend installing the plugin in a test environment first, if possible.

We welcome your feedback on the functionality, the data available to be carried into an Aeon request, and the overall experience for you and your patrons. 

Please let Atlas know if you have any questions or would like help configuring this addon by commenting on this post or emailing



  • Official comment

    A new version of both the plugin and client addon are available to test. Both can be downloaded here:

    Comment actions Permalink
  • If you get null values in the Location or ItemVolume fields in an Aeon request after installing the plug-in, please update your OpenURL Mapping table following the below instructions:

    1. Remove the duplicate entries for ItemAuthor.
    2. Change "instance_top_container_display_string_1" to just "instance_top_container_display_string" (just removing the final "_1")
    3. Change "instance_top_container_long_display_string_1" to just "instance_top_container_long_display_string" (again just removing the final "_1").
    Comment actions Permalink
  • If you use Shibboleth for your Aeon Authentication, changes will need to be made to your Dual Auth Portal. Please contact for assistance. 

    Comment actions Permalink
  • An overview and brief demo is available here:

    Comment actions Permalink
  • Hi Katie,

    We continue to test the plugin here at Georgia Tech and have come across a fairly big issue with which we'd love your help. When we implemented Aeon, y'all worked with us to cluster multiple requests for the same barcode into one transaction. Is there any way to achieve that with the plugin or upcoming revisions to it? If it's relevant, we currently have the plugin set up so that requests are limited to resources with top containers only.

    If it's not possible to cluster requests via the plugin, could you offer us any advice about creating a queue / queues to manage redundant transactions? We're finding it pretty much impossible to imagine keeping track of duplicate requests or consolidating them by hand.

    Other pain points we've encountered so far:

    - Container number and barcode feeding together into our Volume/Box field in the client, so that we need to copy the barcode from that field and paste it into the Barcode field.

    - No location data feeding into requests (the plugin only pulls from the ASpace PUI, right, not from the staff interface as well?)

    Thank you!


    Comment actions Permalink
  • Hi Wendy,

    There is not currently a way to group requests via the ASpace plugin. We have a few follow up questions before offering any suggestions:

    - You mentioned you have limited to resources with top containers only: is this to prevent patrons from submitting too many requests for something with the same barcode or are you still getting multiple requests for the same barcode with that limitation turned on?

    - Is the concern that one person will request multiple items with the same barcode or that multiple patrons will request the same item?

    As for the other two points:

    - Our developers are going to look into the barcode issue - that is currently being pulled from the <#instance_top_container_display_string>|<#instance_top_container_long_display_string> in ASpace. We are going to look into whether or not we can parse out the individual pieces of data so that barcode could be mapped to the appropriate field.

    - I took a look at your OpenURL mapping table and noticed a typo in the Location entry: Could you correct it and try again? If location info is still not coming in, please let us know.


    Comment actions Permalink
  • Hi Katie,

    Thanks so much for your help!

    In answer to your questions:

    We've limited to resources with top containers only for two reasons: 1) we didn't want a unit as large as a whole series to be requestable and 2) as far as I remember (but I could definitely be wrong!), barcode information was not feeding to the Aeon client when we had the plugin configured for archival objects.

    We are concerned about both of the request scenarios you mention -- that one person will request multiple items with the same barcode AND that multiple patrons will request the same item. I've drafted some queue and routing settings that I hope might address these concerns, and I'll email you about that separately to see if you have any advice.

    Thanks to your team for looking into having the barcode feed into the barcode field.

    And thanks, also, for catching the typo in our Location OpenURL mapping. Chris Helms here at GT corrected the typo and reports:

    "Both barcode and location show up in the native request values, but they are not being posted to Aeon.
    Values for request_form not aeon_request_sub:
    location_title = Library Service Center, Archives Module, Archives Module, Compact Shelving [30306, Archives Module:  single location]
    barcode = 50602010846552"

    Thanks so much -- really appreciate your help!


    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post