Additional SMS Carriers

SMS carrier definitions are now included for Google Fi and Republic Wireless. These will be automatically loaded when installing a new Evergreen system; admins who wish to add these definitions during an upgrade can use the following email gateway values:

  • Google Fi: $
  • Republic Wireless: $

Bibliographic Fingerprint Improvements

The bibliographic fingerprint will now incorporate subfields $n and $p from MARC title fields to better distinguish among records of the same series that may share the same title but have a different part. With this change, these MARC records will no longer be grouped together in a Group Formats & Editions search.

The bibliographic fingerprint was also changed to better distinguish among the fields contributing to the fingerprint. This change will help the system distinguish between a record for the movie Blue Steel and another record for the book Blue written by Danielle Steel.

Batch Hold Targeter Speed-up and New Features

Adds a new open-ils.hold-targeter service, supporting new targeting options and runtime optimizations to speed up targeting. The service is launched from a new targeting script, (default location: /openils/bin/

This code has no effect on the existing hold targeter, which is still available as of this release and functions as before.

New Features/Options

  • Adds a global configuration flag circ.holds.retarget_interval for setting the hold retarget interval.
  • --target-all option forces the targeter to process all active holds, regardless of when they were last targeted.
  • --retarget-interval option make is possible to override the new circ.holds.retarget_interval setting via the command line when calling the hold targeter.
  • --skip-viable option causes the hold targeter to avoid modifying the currently targeted copy (i.e. the copy on the pull list) for holds that target a viable (capturable) copy. For skipped holds, no entry is added to the unfulfilled_hold_list. The set of potential copies (hold copy maps) are refreshed for all processed holds, regardless of target viability. This option is useful for 1.) finding targets for holds that require new targets and 2.) adding new/modified copies to the potential copy lists (for opportunistic capture) more frequently than you may want to do full retargeting of all holds.
  • --newest-first option processes holds in reverse order of request_time, so that newer holds are (re)targeted first. This is primarily useful when a large backlog of old, un-targetable holds exist. With --newest-first, the older holds will be processed last.
  • --parallel option overrides the parallel settings found in opensrf.xml for simpler modification and testing.
  • --lockfile option allows the caller to specify a lock file instead of using the default /tmp/hold_targeter-LOCK
  • --verbose option prints progress info to STDOUT, showing the number of holds processed per parallel targeter instance.
  • When configured, hold target loops cycle through all org units (with targetable copies) instead of repeatedly targeting copies at the pickup library when multiple targetable copies exist at the pickup library.
  • When configured, hold target loops prioritize (targetable) org units first by the number of previous target attempts, then by their weight/proximity. This effectively back-fills org units that had no targetable copies during earlier target loops so that they are targeted as many times as other org units (to the extent possible, anyway).


  • Traditional daily hold targeter with a value set for circ.holds.retarget_interval.
  • (Re)target non-viable holds twice a day, only processing holds that have never been targeter or those that have not been re-targeted in the last 12 hours.
/openils/bin/ --skip-viable --retarget-interval "12h"
  • (Re)target non-viable holds twice a day, processing all holds regardless of when or if they were targeted before, running 3 targeters in parallel.
/openils/bin/ --skip-viable --target-all --parallel 3

Add separate make target for translators

For those only interested in building Evergreen translations, a separate "translator" make target has been added to allow for easier installation of i18n prerequisites.

Allow admin to specify where Perl modules will be installed

Add --with-perlbase option to configure to specify an alternative location for installing the Perl modules. This can be useful for setups that want to run the Perl modules from a shared filesystem or environments that need to run multiple versions of Evergreen simultaneously.

Users of --with-perlbase are responsible for ensuring that PERL5LIB is set appropriately.

Addition of missing permissions

Required permissions that were previously missing from the stock data have now been added. If Evergreen sites have already manually added these permissions, the upgrade script will remove the old permission and create the new one, maintaining any maps to permission groups, with the stock permission ID.

get_org_unit_ancestor_at_depth Helper Added to Action Trigger Reactor Helpers

In action trigger templates it’s now possible to call helpers.get_org_unit_ancestor_at_depth($id_or_aou, $depth) in order to retrieve a fleshed aou for the target aou’s ancestor at the chosen depth. This could be used to retrieve the name of the library system rather than a specific branch name, for instance.

Removed unused selfcheck password setting

There was an unused duplicate selfcheck password setting that was removed to avoid confusion over which library setting was supposed to be set to enable passwords for selfcheck. After upgrading, verify that your library policy remains consistent for this setting.

Credit Processor Stripe Settings Permissions

Unprivileged users can retrieve organizational unit setting values for setting types lacking a "view" permission. When the feature adding Stripe credit card processing was added, the upgrade script neglected to add the VIEW_CREDIT_CARD_PROCESSING permission to the organizational unit setting type. This means that anyone can retrieve and view the settings for Stripe credit card processing.

Any system that upgraded from Evergreen version 2.5 to 2.6 is affected. If you use Stripe for credit card processing, it is strongly recommended that you apply this upgrade. Even if you do not use Stripe, applying this upgrade is still recommended. If you did not upgrade from version 2.5 to 2.6 of Evergreen, but started with a later version, applying this upgrade is harmless.