Default filter option for configuration screens

By default, most admin configuration screens in the staff client will now include filters allowing staff to display just those items matching a certain criteria.

Upgrade Notes : IDL2js Locale Support

The following Apache configuration changes are required to support the locale-aware IDL2js module.

# file: eg_vhost.conf

# this is the new part
# capture locale CGI param for /reports/fm_IDL.xml
RewriteCond %{REQUEST_URI} ^/reports/fm_IDL.xml
RewriteCond %{QUERY_STRING} locale=([^&;]*)
RewriteRule . - [E=locale:%1]

# it should be placed just above this existing config section
<LocationMatch /reports/fm_IDL.xml>
    IDLChunkStripPI "yes"
    IDLChunkEscapeScript "no"
    IDLChunkStripComments "yes"
    IDLChunkStripDoctype "yes"
    IDLChunkContentType "application/xml; charset=utf-8"
    AddOutputFilter INCLUDES;IDLCHUNK .xml

Inter-authority linking script

Adds a script called in support-scripts that, when run, will link authority reference headings to authority records that contain the same main entry using a subfield 0. This causes triggers to fill up the authority-authority linking table and allows more information to appear in the bib/authority browse when a displayed heading comes from an authority record that has linked See Also references.

New Updates Tools

Source code for tools to generate the staff clients updates tools were added to Open-ILS/xul/staff_client/external/libmar. These tools replace the downloadable tools from that were previously used to generate the staff client updates files.

They come with their own configuration script and are configured automatically as a subpackage when you configure Evergreen for installation. They are also built and ready for use when you make Evergreen during the installation or upgrade process.

The script that is run when you tell Evergreen to make the staff client updates has been modified to use the new tools.

These tools introduce a dependency on libbz2. This is often only available when installing the libbz2-dev or libbz2-devel packages. Thus this branch introduces a new dependency on the development packages for libbz2 in Evergreen.

Nothing in the user facing behavior of building updates changes with these tools. They are drop-in replacements for the previous tools and other than the new dependency on libbz2, you don’t even need to know that they are there.

These tools were added to Evergreen to be an aid in portability to operating systems other than Linux. They also remove a dependency on a third-party tool, that is typically downloaded as a binary. Module is a mod_perl module for Apache that works with Evergreen to generate callings lists for patron holds. It outputs a csv file that can be fed into an auto-dialer script to call patrons with little or no staff intervention. It is accessed and configured via a special URL and passing any parameters as a “Query String” on the URL. The parameters are listed in the table below.

Table 4.1. Parameters for the phonelist program:


Your Evergreen login. Typically your library’s circ account. If you leave this off, you will be prompted to login.


The password for your Evergreen login. If you leave this off you will be prompted to login.


The ID of the system or branch you want to generate the list for (optional). If your account does not have the appropriate permissions for the location whose ID number you have entered, you will get an error.


If present, skip patrons with email notification (optional).


Add a count of items on hold (optional). Only makes sense for holds.


Makes a list of patrons with overdues instead of holds. If an additional, numeric parameter is supplied, it will be used as the number of days overdue. If no such extra parameter is supplied, then the default of 14 days is used.

The URL is


A couple of examples follow:


The above example would sign in as user circuser with password of “password” and get a list of patrons with holds to call who do not have email notification turned on. It would run at whatever branch is normally associated with circuser.


The above example would do more or less the same, but you would be prompted by your browser for the user name and password.

If your browser or download script support it, you may also use conventional HTTP authentication parameters.


The above logs in as “user” with “password” and runs overdues for location ID 2.

"Purge Holds"

Similar to purging circulations one may wish to purge old (filled or canceled) hold information. This feature adds a database function and settings for doing so.

Purged holds are moved to the action.aged_hold_request table with patron identifying information scrubbed, much like circulations are moved to action.aged_circulation.

The settings allow for a default retention age as well as distinct retention ages for holds filled, holds canceled, and holds canceled by specific cancel causes. The most specific one wins unless a patron is retaining their hold history. In the latter case the patron’s holds are retained either way.

Note that the function still needs to be called, which could be set up as a cron job or done more manually, say after statistics collection. A new script, purge_holds.srfsh, is added that can be used to purge holds from cron.

Action Trigger Event Repeatability

Action Trigger Event Definitions have a new field, "Event Repeatability Delay". This feature allows events to be repeated after the designated delay interval. An example of this is sending a notification email when a patron’s library card expires. If the library extends the expiration date on that card, we then need a way to send another notification email when that same card expires again. Before, the Action Trigger processor only created a new event if the event definition for that target had never been run before. But now it allows repeating of the event after the delay interval, if present.