Evergreen 3.1 Release Notes

The Evergreen Web Staff Client now includes a section called Tests linked from Administration → Workstation. The Tests page houses a simple tool that can be used to test the latency of the websocket connection between the client and the server (via the opensrf.echo service).

This page displays which Evergreen host server is being queried. Upon hitting the blue "Start Test" button for the first time, it will issue 10 sequentially fired requests in order to get a solid initial average. Clicking the button a second time will take one more measurement and recalculate the average latency. The results can be copied to clipboard for troubleshooting purposes and also cleared from display.

The marc_export support script now has a --uris option (short form: -u) to export records with located URIs (i.e. electronic resources). When used by itself, it will export only records that have located URIs. When used in conjunction with --items, it will add records with located URIs but no items/copies to the output. If combined with a --library or --descendants option, this option will limit its output to those records with URIs at the designated libraries. The best way to use this option is in combination with the --items and one of the --library or --descendants options to export all of a library’s holdings both physical and electronic.

The Concerto sample data set now includes patron surveys, questions, answers, and responses.

The practical purpose of Virtual Index Definitions is to supply an Evergreen administrator with the ability to control the weighting and field inclusion of values in the general keyword index, commonly referred to as "the blob," without requiring tricky configuration that has subtle semantics, an over-abundance of index definitions which can slow search generally, or the need to reingest all records on a regular basis as experiments are performed and the configuration refined. Significant results of recasting keyword indexes as a set of one or more Virtual Index Definitions will be simpler search configuration management, faster search speed overall, and more practical reconfiguration and adjustment as needed.

Previously, in order to provide field-specific weighting to keyword matches against titles or authors, an administrator must duplicate many other index definitions and supply overriding weights to those duplicates. This not only complicates configuration, but slows down record ingest as well as search. It is also fairly ineffective at achieving the goal of weighted keyword fields. Virtual Index Definitions will substantially alleviate the need for these workarounds and their consequences.

When 2 or more bib records are merged, all records involved are stamped with a new merge_date value. For any bib record, this field indicates the last time it was involved in a merge. At the same time, all subordinate records (i.e. those deleted as a product of the merge) are stamped with a merged_to value indicating which bib record the source record was merged with.

In the browser client bib record display, a warning alert now appears along the top of the page (below the Deleted alert) indicating when a record was used in a merge, when it was merged, and which record it was merge with, rendered as a link to the target record.

This feature adds a bit of convenience to a common task: checking out an item on hold to another patron (typically a family member or helper).

When you checkout the item, you will get a pop-up window with warnings associated with this item. The "ITEM_ON_HOLDS_SHELF" message is now expanded to

The initial value of the checkbox is derived from the circ.clear_hold_on_checkout organizational setting.

If the operator has CANCEL_HOLD privilege, then if the checkbox is checked and the checkout is allowed to proceed, the hold will be cancelled with a note that the item was checked out to another patron.

This feature is available in the browser-based staff client.

The Evergreen web staff client now includes a patron billing statement, which summarizes a patron’s bills, credits and payments in a familiar layout. This can be found on the "Statement" tab of the Patron Bill Details page. (From the Patron Bills page, double-click a row to view its details, or choose "Full Details" from the Actions menu.)

Previously, billings had to make do with a single timestamp attempting to fill two different roles. In the case of an overdue fine, the timestamp represented the end of the fine period for that billing, while for all other fines, the timestamp was merely the time the bill was created. This setup generally worked, but not without confusion, and limited our ability to understand and process the data.

Billings will now have up to three timestamps: a create date, and when applicable, a fine period start and a fine period end. This clarifies and simplifies things like backdating, retrospective fine generation, account balancing for negative balance avoidance, and billing timeline views.

The Copy Alerts feature allows library staff to add customized alert messages to copies. The copy alerts will appear when a specific event takes place, such as when the copy is checked in, checked out, or renewed. Alerts can be temporary or persistent: temporary alerts will be disabled after the initial alert and acknowledgement from staff, while persistent alerts will display each time the alert event takes place. Copy Alerts can be configured to display at the circulating or owning library only or, alternatively, when the library at which the alert event takes place is not the circulating or owning library. Copy Alerts can also be configured to provide options for the next copy status that should be applied to an item. Library administrators will have the ability to create and customize Copy Alert Types and to suppress copy alerts at specific org units.

Copy alerts can be added via the volume/creator and the check in, check out, and renew pages. Copy alerts can also be managed at the item status page.

Copy alert types can be managed via the Copy Alert Types page in Local Administration, and suppression of them can be administered via the Copy Alert Suppression page under Local Administration.

Users with the appropriate permissions now have the ability to place multiple title/metarecords holds at once. This feature is especially beneficial for book clubs and reading groups, which need to place holds on multiple copies of a title.

In order to use the feature:

When placing a title or metarecord hold, a Number of copies field will display for these users. This field is not available when placing part, volume or copy holds.

This feature does not change the way in which the system fills holds. The multiple holds will fill in the same way that they would if the user had placed multiple holds separately.

The grid in the patron "items out" page in the Evergreen web staff client has two new columns indicating the number of notifications generated for a given loan and the date of the most recent notification. These columns will allow circulation staff to better respond to patron questions about whether they were sent notification about an overdue item.

The columns are based on the number of completed Action Trigger events on the loan that have a checkout.due hook. In other words, they would include overdue and courtesy notices.

A new library setting, "Exclude Courtesy Notices from Patrons Itemsout Notices Count", if set will cause the notice count and date fields to exclude courtesy notices.

Adds a mailto link to the patron’s email in their profile so it can be clicked to send and email to the patron. No new settings or permissions are included in this feature.

Adds a new library setting, circ.staff_placed_holds_fallback_to_ws_ou, that helps determine the hold pickup library in cases where patrons don’t have a preferred hold pickup library in their account and a staff member is placing the hold on their behalf.

Evergreen now highlights search terms on the public catalog’s main search results page, the record detail page, and intermediate pages such as metarecord grouped results page. Highlighting search terms will help the user determine why a particular record (or set of records) was retrieved.

Highlighting of matched terms uses the same stemming used to accomplish the search, as configured per field and class.

This feature will help the user more quickly determine the relevance of a particular record by calling their attention to search terms in context. Lastly, it will help familiarize the user with how records are searched, including which fields are searched as well as exposing concepts like stemming.

You can turn off search term highlighting by uncommenting the line search.no_highlight = 1; in config.tt2.

When highlighting is generally enabled, it may be turned on or off on a per-page basis through the use of a UI component which will request the page again without highlighting.

Highlighting of terms uses Template::Toolkit-driven CSS. A generic CSS class identifying a highlighted term, along with CSS classes identifying the search class and each search field are available for use for customization of the highlighting. A stock CSS template is provided as a baseline upon which sites may expand.

The Shelving Location filter now displays on the advanced search page when a search is scoped to a library system, not just to an individual branch. If a library system is selected as the Search Library, the shelving location limiter will display any shelving location that is owned by the selected system or by the consortium. It will NOT display shelving locations owned by child branches.

We now allow record attribute definitions to extract data using more than one strategy (XPath, tag+subfield, fixed field, etc.) as long as the values from various sources would, after normalization, have the same shape.

A new setting controls whether badges (popularity, etc.) are displayed in the catalog. If you do not wish badges to be displayed, set the ctx.hide_badge_scores setting to "true" in config.tt2.

When using pg_restore to restore an Evergreen database, some of the indexes used to speed up patron searches on names and usernames could be lost.

This release fixes the underlying issue and re-creates the indexes in question.