Evergreen 2.10-beta Release Notes

A new "paid" label appears along the bottom of each line item in the PO display when every non-canceled copy on the line item has been invoiced.

Fund debits linked to an invoice are now marked as paid (encumbrance=false) when the invoice is marked as closed/complete instead of at invoice create time. This is particularly useful for EDI invoices which may be created well in advance of receipt and payment.

The actions selector is now always visible in the purchase order view, even when no line items exist. With this, users can print PO’s that only contain direct charges.

The custom "Add Brief Record" button is no longer present, since the same action is accessible via the now-visible selector.

The services that connect directly to the PostgreSQL database (and Clark Kent) now look for an application_name parameter as part of the database login credentials specified in opensrf.xml. If present, the value is used to set the application name Pg connection value; this in turn shows up in the Postgres pg_stat_activity table and Pg’s logs.

To improve privacy and security, Evergreen now stores less data about credit card transactions. The following fields are no longer stored:

Additionally, a tool has been added to Evergreen for clearing the last 4 digits of the credit payment from the database after payments reach a certain age.

If you are using the AstCall action/trigger reactor to generate callfiles to send to an Asterisk server, until now the only place to specify the relevant configuration was in opensrf.xml. However, this restricted an Evergreen consortium to using only one Asterisk instance.

Now, the telephony parameters can also be specified as A/T event parameters, allowing per-library configuration.

The batch juv_to_adult.srfsh script that, when set up as a cronjob, is responsible for toggling a patron from juvenile to adult now honors the age value set in the library setting named "Juvenile Age Threshold" (global.juvenile_age_threshold). When no library setting value is present at a given patron’s home library, the value passed in to the script will be used as a default.

A new reporting source is added, "Hold/Copy Ratio per Bib and Pickup Library (and Descendants)", that, for each bib that has a hold request on it or any of its components, calculates the following:

This source differs from the "Hold/Copy Ratio per Bib and Pickup Library" source by including all descendants of the organization unit one is filtering on.

One use case is allowing a multi-branch system within an Evergreen consortium that doesn’t do full resource sharing to readily calculate whether additional copies should be purchased for that system.

A new action/trigger event definition ("New User Created Welcome Notice") has been added that will allow you to send a notice after a new patron has been created, based on the actor.usr create-date field.

This notice can be used for various tasks.

Enable this event in the staff client at Admin → Local Administration → Notifications / Action Triggers.

Evergreen user passwords are now stored with additional layers of encryption and may only be accessed directly by the database, not the application layer.

All API changes are backwards compatible with existing 3rd-party clients.

HTML reports can now be sorted by clicking on the header for a given column. Clicking on the header toggles between sorting the column in ascending and descending order. Note that sorting is available only when there are at most 10,000 rows of output.

The AccM, Comp, CrTp, EntW, Cont, FMus, LTxt, Orig, Part, Proj, Relf, SpFm, SrTp, Tech, and TrAr fixed fields have been defined and coded value maps added so they can also be used for Advanced Searches or adding to Composite Value Maps.

Note that AccM, Cont, LTxt, Relf, and SpFm are compositite values based on the values of "helper" fields like AccM(1), AccM(2), and so on. These positional fields can be ignored.

Coded value maps have also been added for Cont, Ctry, and DtSt, and the Time field has been defined. All of these fields are now available in the Fixed Field Editor when editing the appropriate records.

When inspecting a queue in MARC Batch Import/Export, there is now a link to download to MARC file any records in the queue that were not imported into the catalog. This allows catalogers to quickly manipulate the records that failed to import using an external tool, then attempt to import then again.

The authority linker script now supports linking the MARC21 field 800 (series added entry - personal name) to authority records.

The MARC stream importer script, commonly used with external services like OCLC Connexion, is now capable of importing authority records in addition to bib records. A single running instance of the script can import either type of record, based on the record leader.

Users often miss the list of parts on the Place Holds screen, leading to many title-level holds on records where only one or two libraries may have unparted copies.

A new option is available to change this display so that a part is selected via radio buttons instead of the traditional dropdown menu. This display increases the visibility of parts on the Place Holds screen and also forces users to make an explicit choice.

To enable the alternate display, set the enable.radio.parts option to true in parts/config.tt2.

The web staff interface now includes a patron editor/registration form that is written using AngularJS, leading to faster and more responsive patron editing. This feature is currently available in preview mode, but supports the following actions:

After copy checkin, if the copy is in-transit, display a special message in the transit alert dialog and in the printed transit receipt (optionally, via macro) if the copy is in (or, rather, will be once it arrives at its destination) a non-active copy status.

A new library setting has been added which enables a library to prevent their patrons from being opted in at other libraries.

For example, consider the following org unit hierarchy:

Suppose that SYS1 wishes to prevent its patrons from being opted in at SYS2. To accomplish this, it sets the value of the "Restrict patron opt-in to home library and related orgs at specified depth" setting to 1, meaning that patrons at SYS1 libraries at or below that depth in the org tree cannot be opted in by libraries outside that part of the org tree. Thus, BR1 patrons can be opted in at BR2, but not at BR3 or BR4.

(This setting is distinct from the "Patron Opt-In Boundary" setting, which merely determines the depth at which Evergreen prompts for the patron to opt in.)

Standing penalties now have an ignore_proximity field that takes an integer value. When set, the value of this field represents the proximity from the user’s home organizational unit where this penalty will be ignored for purposes of circulation and holds. Typical values for this field would be 0, 1, or 2 when using a standard hierarchy of Consortium → System → Branch → Sublibrary/Bookmobile. A value of 1 would cause the penalty to be ignored at the user’s home organization unit, its parent and/or immediate child. A value of 2 should cause it to be ignored at the above as well as all sibling organizational units to the user’s home. In all cases, a value of zero causes the penalty to be ignored at the user’s home and to apply at all other organizational units. If the value of this field is left unset (or set to a negative value), the penalty will still take effect everywhere using the normal organizational unit and depth values. If you use a custom hierarchy, you will need to figure out any values greater than 0 on your own.

The ignore_proximity does not affect where penalties are applied. It is used when determining whether or not a penalty blocks an activity at the current organizational unit or the organizational unit that owns the copy involved in the current transaction. For instance, if you set the ignore_proximity to 0 on patron exceeds overdue fines, then the patron will still be able to place holds on and checkout copies owned by their home organizational unit at their home organizational unit. They will not, however, be able to receive copies from other organizational units, nor use other organizational units as a patron.

Patron checkout history is now stored in separate, dedicated database table instead of being derived from the main circulation data. This allows us to age/anonymize circulations more aggressively, since they no longer need to stick around in cases where they represent a patron’s opt-in checkout history.

This has a number of patron privacy implications.

A new column picker option showing the number of holds for a given item will now be available in various interfaces displaying item information, including the patron’s Items Out tab and the Item Status, Check Out, Check In, Renew Item and Record In-House Use screens.

Note: Because the holds count is generated from the hold_copy_map, newly-added items and items in a non-holdable status will not display accurate hold counts until 24 hours after they have been added to the system or moved to a holdable copy status.

The client now supports using distinct images for hold, transit, and booking reservation popup windows and slips. In addition, three new images have been provided, replacing the turtle that was previously. The turtle file is still available in the images directory for those sites that still wish to use it.

The following public methods, which were both broken and not in use, are removed:

Patrons can now delete titles that they do not wish to appear in their Check Out History.

Deleted titles will also not appear in the downloaded CSV file.

When disabling checkout and/or holds history in the public catalog’s Search and History Preferences tab, patrons will be warned that the operation is irreversible when history data exists that will be deleted as part of the update.

The list of copies on the record details page now includes the part label in the default sort order.

Specifically, copies are now sorted by (in order), org unit, then call number, then part label sortkey, then copy number, and finally barcode.

Previously, the hierarchy was org unit, then call number, then copy number, and finally barcode

A common usage of the catalog is to do a search in a restricted scope, like a local library. When the results are lacking, the search is repeated in a consortium-wide scope. This feature provides an optional button and checkbox to alter the depth of the search to a defined level.

This feature can be turned off from config.tt2.

A limiter to exclude electronic resources from search results is now available on the advanced search screen and from the search results page. This limiter will exclude any search results with an item form of o or s. This limiter will be applied on top of any other format limiters used in the search.

The checkboxes are disabled by default; to display them in both places, please toggle the ctx.exclude_electronic_checkbox setting in config.tt2.

Evergreen’s unAPI support now includes access to many more record types. For example, the following URL would fetch bib 267 in MODS32 along with holdings, volume, copy, and record attribute information:

https://example.org/opac/extras/unapi?id=tag::U2@bre/267{holdings_xml,acn,acp,mra}&format=mods32

To access the new unAPI features, the unAPI ID should have the following form:

The stock indexing definitions now include a search and facet index on the form/genre field (tag 655). This allows genre links in the public catalog record display to retrieve works in the same genre. The public catalog genre links will no longer display content from the 659 MARC fields.

The genre facet will also display by default in the public catalog. A partial reingest during upgrade is required to use this index.

Catalog search now sets a limit on the number of facets retrieved per defined facet field. Setting a limit is useful so that `open-ils.cstore backends don’t end up needlessly consuming memory when fetching facets for a large result set; if a broad search retrieves over 10,000 author facets (say), even the most persistant user is not going to actually look at all of them. Fetching fewer facets can also slightly speed up generation of search results.

The limit is controlled by a new global flag, search.max_facets_per_field, whose label is "Search: maximum number of facet values to retrieve for each facet field". The default limit value is 1,000, but lower values (e.g., 100) are perhaps even better for most catalogs.