Skip to main content

Managing your ArchivesSpace Plugins

info

Please see the webinar Proactive Change Management for Plugins for critical advice about the use of plugins in ArchivesSpace.

This article is written for users who already have plugins installed on their instance of ArchivesSpace and are looking for ways to better manage them and anticipate concerns over time. For advice on evaluating plugins to be installed, please see our related article What to Consider when Evaluating Third-Party ArchivesSpace Plugins.

Know what they are and what they do​

Start with these most basic questions about your plugins:

  1. What plugins do you have installed on your server(s)?

    • If you are an Enterprise customer, which plugins are on your Sandbox versus Production?

  2. What does each plugin do?

  3. What function does each plugin serve in your environment and your workflows?

  4. Do you know what configurations you have in place for configurable plugins?

  5. Do you know what party is responsible for each of the plugins you have installed?

This article will help walk you through how to answer each of those questions about the plugins you have installed. Please read on.

Know how to access them​

By hosting at Atlas Systems you have unique access to the plugins that are running on your server(s), and that's made possible by the Atlas Hosting plugin. This is a plugin developed by Atlas that allows you to see (and download) the plugins installed on your server.

info

Please note, the following steps will require use of either the admin account (the account literally called "admin") and/or an ArchivesSpace user account with system administrator (sysadmin) privileges.

What plugins you have installed on your server(s)?​

You can determine this in one of two ways:

  1. While signed in as the admin on the staff interface, navigate to System and then select System Information. On that page, look for the heading APPCONFIG. Under that heading, look for the heading called plugins. The list you see there are the plugins you have installed on this server. It will look something like: ["custom_locales", "atlas_hosting", "local", "lcnaf", "aeon_fulfillment"]

  2. While logged in as a user with sys admin privileges, click the Plug-ins drop-down menu next to your username icon and select Atlas Hosting. Click Download Plugins in the upper right of that page. This page will list the plugins on your server and allow you to download them if necessary.

If you are an Enterprise customer hosting more than one instance with us, simply repeat these steps to compare your Production and Sandbox servers to understand what plugins you have installed on your different servers.

Know what each plugin does​

The next most important piece of information that you will need in managing your plugins is to understand what each plugin does.

Since you are reading this article at Atlas Systems, it's best to start with Atlas plugins.

info

For more details about the parties responsible for plugins, see ArchivesSpace Plugin Responsibility and Troubleshooting.

Atlas Plugins​

  • atlas_hosting: Atlas Hosting is where Atlas controls certain aspects of your hosted experience and is the plugin that allows for plugin downloads (more on that below). Atlas maintains that plugin; you the customer cannot and should not modify it.

  • custom_locales: This is where Atlas maintains changes to your YML files, or the files that control how fields are labeled in ArchivesSpace. Atlas maintains that plugin; you the customer can modify it if you choose to, otherwise we will modify it for you. More information is available in Managing your ArchivesSpace Customizations with Atlas Systems.

  • aeon_fulfillment: Aeon customers will recognize this plugin as the one that allows for integration with Aeon. Atlas maintains that plugin.

Your plugins​

  • local: The local plugin refers to a plugin directory called l-o-c-a-l which ships blank by default. This means that all servers have a plugin directory called local, but whether or not there is actually something in it will vary. We at Atlas maintain your logo in the local plugin, and thus you are not responsible for the logo changes. However...

  • ? Whether or not you have other plugins installed at Atlas will vary by institution and even by server (Production versus Sandbox, for Enterprise customers). We encourage users to use plugin names specific to your institution to make this clear, like "institution-name_branding".

Third Party Plugins​

For third-party plugins, the best piece of information you can have is the link to the source repository where each plugin is maintained. This is a vital thing to keep track of, as the repository itself is key to understanding what the plugin is, what it does, how it can be configured (if at all), and its maintenance and compatibility over time.

If you do not already know the repository where a plugin originated (usually in GitHub), then you will need to find it. A quick search of "[plugin name] archivesspace plugin github" is usually all it takes.

For example, "user_defined_in_basic archivesspace plugin github" brings you to https://github.com/hudmol/user_defined_in_basic and "digitization_work_order archivesspace plugin github" brings you to https://github.com/hudmol/digitization_work_order.

From these pages you should be able to ascertain:

  • What the plugin does
  • Whether it's configurable

What function does each plugin serve in your environment and your workflows?​

The last question -- how you actually use this plugin or what workflows rely on it? -- will need to be answered by you about your own local practices. But this is a key question to keep asking because sometimes site stop using plugins, but they remain installed. Are you still using it? If the answer is no, remove the plugin to reduce the probability of it being incompatible.

Do you know what configurations you have in place for configurable plugins?​

Some plugins are simply enabled and that is the only step. In these cases, you will not need to keep track of configurations because there will not be any.

But some plugins are configured in addition to being installed. These configurations can be handled in the plugin directory itself or in the config.rb, the main configuration file for ArchivesSpace.

Whether or not a plugin is configurable is most easily answered by reading the documentation of that plugin

Know what party is responsible for each​

Atlas maintains a separate article on this topic: ArchivesSpace Plugin Responsibility and Troubleshooting.

By undertaking all the steps above, you can populate a quick reference guide that looks something like this:

Plugin NameRepository LinkResponsible PartyWhat does it do?Testing behaviorCompatibility notes
localDownload from staff interfaceCustomer (you)We added some lines to add a custom footer to the PUIBe sure footer is present in each new ASpace updateTested fine in 3.3.1 and 4.0
user_defined_in_basichttps://github.com/hudmol/user_defined_in_basicHudson Molonglo (third party)Moves our Date 1 field to the top of accession recordsConfirm this is present after every version updateTested fine in 2.7.1 through 4.0
custom_localesDownload from staff interfaceAtlas Systems (first party)Maintains our label changesCheck known labels changes after every updateAtlas keeps compatible

Know how to update them​

Please see our related article: Delivering and Maintaining your ArchivesSpace Plugins