1 Evergreen 2.11 Release Notes
2 ============================
9 This release contains several bugfixes improving on Evergreen 2.11.0
11 * A fix to that provides alphabetical sorting to the fund selector in
12 the Acquisitions Selection List -> Copies interface.
13 * A fix to the web client check in screen allowing users to click the
14 title of the checked-in item to retrieve the bib record for that item.
15 * The addition of a progress bar that displays when conducting a patron search in the web client.
16 * A fix to the web client patron interface so that total Items Out in the
17 patron summary now includes overdue and long overdue items. It will also
18 include Lost and Claims Returned items when the appropriate library
20 * A change to the public catalog My Account screen where the font for
21 leading articles will now be smaller when sorting a list by title.
22 * A fix to subject links in the catalog's record summary page so that
23 periods are no longer stripped from resulting subject searches, leading
24 to more accurate results when those links are clicked.
25 * A fix to avoid unint warnings in the logs for prox_cache in
26 open-ils.circ.hold.is_possible.
27 * A fix to rounding errors that occured when summing owed/paid totals
28 for display in the catalog's credit card payment form.
29 * A change to sort behavior in the My Account screens. Previously, a
30 third click on a column header returned the list to its original sort
31 order. Clicking column headers will now simply toggle the sort
32 between ascending and descending order.
33 * The Permalink option on the catalog's record summary page will now be
34 hidden in the staff client because clicking the link in the client led
35 to no discernable change for users.
36 * A fix to the display of permanent lists in the catalog, which had broken
38 * A fix to the text of a notice that displays when migrating circulation
39 history during the upgrade to 2.10.
40 * An improvement to the performance for the lookup of a user's circ
41 history by adding an index on action.usr_circ_history(usr).
42 * The addition of Spanish as a supported translations so that
43 it can be configured as a language option in the public catalog.
47 We would like to thank the following individuals who contributed code,
48 tests and documentation patches to the 2.10.8 point release of
67 Tablefunc Extension No Longer Required
68 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
69 Changes in the behavior of the connectby function in PostgreSQL 9.5
70 have prompted its removal from the database. It is easier for
71 Evergreen to maintain compatibility with previous versions of
72 PostgreSQL without this function.
74 By eliminating the use of the connectby function, we eliminate the
75 requirement for the tablefunc database extension. It is no longer
76 installed when the database is created. If you are upgrading and wish
77 to remove it from your database, you may run the following statement
78 in the database to drop it:
80 DROP EXTENSION tablefunc;
96 Add Date Header to Action Trigger Email/SMS Templates
97 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
98 The Date: header specified in RFC 2822 has been added to the seed data
99 for the example Action Trigger email and SMS templates, but no attempt
100 has been made to automatically modify existing templates. To add this
101 header (and end any "Why are my library emails from 1969/70?" questions
102 you may have heard) make sure the following lines are in all templates
103 that use the SendEmail or SendSMS reactors:
105 The first is already in most sample templates, but you may need to add
106 it to the top of any custom templates:
109 And this line should be inserted into the header block of each template:
110 `Date: [%- date.format(date.now, '%a, %d %b %Y %T -0000', gmt => 1) %]`
116 Support for Ubuntu 16.04
117 ^^^^^^^^^^^^^^^^^^^^^^^^
118 Adds support for Ubuntu Xenial Xerus (16.04).
127 User activity types are now set to transient by default for new
128 Evergreen installs.. This means only the most recent activity entry per
129 user per activity type is retained in the database.
131 This change does not affect existing activity types, which were set to
132 non-transient by default. To make an activity type transient, modify the
133 'Transient' field of the desired type in the staff client under Admin ->
134 Server Administration -> User Activity Types.
136 Setting an activity type to transient means data for a given user will
137 be cleaned up automatically if and when the user performs the activity
138 in question. However, administrators can also force an activity
139 cleanup via SQL. This is useful for ensuring that all old activity
140 data is deleted and for controlling when the cleanup occurs, which
141 may be useulf on very large actor.usr_activity tables.
143 To force clean all activity types:
146 ------------------------------------------------------------
147 SELECT actor.purge_usr_activity_by_type(etype.id)
148 FROM config.usr_activity_type etype;
149 ------------------------------------------------------------
151 NOTE: This could take hours to run on a very large actor.usr_activity table.
162 Authority Record Import Updates Editor, Edit Date.
163 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
164 Importing an authority record via MARC Batch Import/Export now causes the
165 authority record's editor and edit_date fields to be updated. The editor
166 value may come from the MARC 905u field or, if none is present, the user
167 performing the import.
172 Authority Propagation Updates Bib Editor / Edit Date
173 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
174 When a bib record is automatically updated as a result of the
175 modification of a linked authority record, the bib record's "Last Edit
176 Date/Time" and "Last Editing User" fields will be updated to match the
177 time of the update and the editor of the modified authority record.
179 A new global flag is available to control this behavior called
180 'ingest.disable_authority_auto_update_bib_meta' ("Authority Automation:
181 Disable automatic authority updates from modifying bib record editor
182 and edit_date"). When enabled, theses fields will not be updated. By
183 default, this setting is disabled.
185 An additional speed improvement is included in this feature. No attempt
186 will be made to update linked bib records when the normalized heading of
187 the modified authority record is unchanged by the authority record update.
192 Bibliographic Record Source Now Copied to 901$s
193 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
194 If a bibliographic record has a source set, the name of that source
195 is now copied to the 901$s whenever the record is created or updated.
196 This allows the source to be used for record matching and MARC
202 Option to Update Bib Source and Edit Details on Record Import
203 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
204 When importing records through the client, users will now have the ability to
205 define whether the bib source, last editor, and last edit date should be updated
206 on a record merge/overlay.
208 In MARC Batch Import / Export, select the _Merge / Overlay_ tab. Each entry in
209 the table has a value in the new _Update bib. source_ column. If that value is
210 True, then the bib source, last editor, and last edit date will be updated.
212 The two system-defined entries have been pre-set to appropriate values (Full
213 Overlay = true; Match-Only Merge = false).
223 Staff Client Honors Aged Circulations
224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
226 The browser and XUL clients now better represent copy checkout history
227 by honoring and displaying information from aged circulations.
229 * Browser client 'Recent Circ History' and the analogous XUL client
230 'Circulation History' tabs show summary data for aged circulations
231 as well as regular/active circulations. When aged circulation data
232 is displayed, any references to patron names are replaced by the string
233 "<Aged Circulation>".
235 * Browser client 'Circ History List' and the analogous XUL client
236 'Last Few Circulations' tabs behave as above, plus their 'Add
237 Billing' buttons are disabled when displaying aged circulation data.
239 * XUL client 'Retrieve Last Patron' actions from various UI's report,
240 "Item XXX circulation is an aged circulation and has no linked user".
241 Browser client analog uses 'Circ History List' instead; no additional
248 "Canceled Transit" Item Status
249 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
251 Previously, when a transit was aborted, the transited item would either go into
252 "Reshelving" status or would return to whatever status it was in when it went
253 into transit, even when the item itself was in a different status (including
254 "Checked out"). Now, for most transits that get aborted, the item is put into a
255 new status, "Canceled Transit", which signals to staff the actual state of the
256 item. This feature only affects items with a status of "In transit" and does
257 not affect items that were in the following statuses at the time they were sent
268 * Any custom statuses
270 This change should help clear up confusing situations caused by the previous
271 "abort transit" behavior, such as items showing "Available" when they are actually
272 en route, and patrons' items mysteriously disappearing from their accounts and
273 showing "Available" at the item-owning library without evidence of check-in.
278 Copy Status "Is Available" Flag
279 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
281 A new boolean field is now available for copy statuses to indicate when copies
282 having a given status should be considered available. The field has 2 main
285 1. Checking out an "available" copy will no longer result in an override-able
286 "COPY_NOT_AVAILABLE" alert for staff. The copy will checkout without
289 2. "Available" copies will appear in catalog searches where "limit to
290 available" is selected as a search filter.
292 By default, the "Available" and "Reshelving" statuses have the "Is Available"
293 flag set. The flag may be applied to local/custom statuses via the copy
294 status admin interface.
300 Email Checkout Receipts
301 ^^^^^^^^^^^^^^^^^^^^^^^
302 This feature allows patrons to receive checkout receipts through email
303 at the circulation desk and in the Evergreen self-checkout interface.
304 Patrons need to opt in to receive email receipts by default and must
305 have an email address associated with their account. Opt in can be staff
306 mediated at the time of account creation or in existing accounts.
307 Patrons can also opt in directly in their OPAC account or through patron
308 self-registration. This feature does not affect the behavior of
309 checkouts from SIP2 devices.
311 Patrons can opt in to receive email checkout receipts by default via
312 a new _Email checkout reciepts by default_ patron setting.
314 This feature also enhances the patron staging tables so that patron
315 settings can be chosen during self-registration.
317 The web staff interface's checkout screen now includes a "Quick
318 Receipt" button that allows staff members to generate a receipt
324 Set Per-OU Limits on Allowed Payment Amounts
325 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
326 Two new settings have been added to prevent clerks from accidentally clearing
327 all patron bills by scanning a barcode into the Payment Amount field, or
328 accidentally entering the amount without a decimal point (such as you
329 would when using a cash register).
331 Both settings are available via the Library Settings Editor. The _Payment
332 amount threshold for Are You Sure? dialog_ (ui.circ.billing.amount_warn)
333 setting identifies the amount above
334 which staff will be asked if they're sure they want to apply the payment.
335 The _Maximum payment amount allowed_ (ui.circ.billing.amount_limit)
336 setting identifies the maximum amount of
337 money that can be accepted through the staff client.
339 These settings only effect the staff client, not credit
340 cards accepted through the OPAC, or direct API calls
341 from third party tools.
351 Additional Fields Available for Display in Some Interfaces
352 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
353 The holds age protection field will now be available for display in the
354 following interfaces:
356 * Item status list view column picker
357 * Item status alternate view
358 * Holdings maintenance column picker
360 The asset.copy.cost field, which records the amount paid for an item when
361 an invoice is processed, will be available for display in the following
364 * Items status list view column picker
365 * Item status alternate view
377 Merge Notification Preferences Tables in TPAC
378 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
379 The patron notification preference page in the public catalog
380 used to have two tables, separating notification settings
381 based on their source. Since that distinction does not matter
382 to patrons, and since the two tables aren't styled consistently,
383 they are merged together.
388 Improved Holds Screens in My Account
389 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
390 The grids in the My Account _Items on Hold_ and _Holds History_ interfaces are
391 simplified. Data previously contained in their own Activate, Active, and Date
392 Fulfilled columns are now incorporated into the Status column. To further
393 declutter the interface, the holds queue position will only show when the user
394 most needs the information - before the hold has been captured.
396 Distinct CSS classes have also been added for each hold status and each date
397 that could potentially display in these holds interfaces. A new default style
398 highlights the _Available_ status in green and the _Suspended_ status
406 Popularity Boost for Ranking Search Results
407 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
409 This feature uses factors such as circulation and hold activity, record and item age, and item ownership counts to generate popularity badges for bibliographic
410 records. Each badge will have a five-point scale, where more points indicates a more popular record. The average of the badge points earned by each record will constitute a "popularity rating". The number and types of badges will break ties for average popularity, and relevance will sort items with like popularity.
412 A new sort axis of popularity is created to sort first on the weighted average popularity of each record, followed by the query-specific relevance available today. A new option is created in the dropdown called _Most Popular_ that sorts on the combination of "activity metric" (aka badge ranking, aka popularity) first and then the existing, stock relevance ranking when those are equal. For instance, given two records that both have a badge ranking of "4.5", they sort in the order of the query relevance ranking that is calculated today as a tie breaker. Those two records will sort above other records with lower badge rankings regardless of what today's relevance ranking says about them.
414 In addition, a new sort axis of _Popularity-Adjusted Relevance_ is created that augments the normal Relevance sort with a normalized popularity value by multiplying the base relevance by a value controlled by a new global flag, generally set to a decimal number between 1 and 2.
416 Finally, there will continue to be a pure _Relevance_ sort option, which is the version that exists today.
418 Administrators can comment out one of the available sort methods by editing the
419 filtersort.tt2 file.A global flag will allow Evergreen sites to select a default sort method.
424 Administrative interfaces to configure badges are only available in the web
425 client. Administrators can also configure badges directly via the database.
427 Available Popluarity Parameters available for badges include:
429 * Holds Filled Over Time
430 * Holds Requested Over Time
432 * Circulations Over Time
433 * Current Circulation Count
436 * Holds/Holdable Ratio
437 * Percent of Time Circulating
438 * Bibliographic Record Age (days)
439 * Publication Age (days)
440 * Available On-Line (for e-books, etc)
443 Badges can be configured to apply to a targeted group of bibliographic records
444 based on the following available filters:
447 * Bibliographic source
448 * Circulation modifier
449 * Copy location group
451 Badges can also be be restricted to materials owned by a specific organiztional
454 This new feature comes with a starter badge based on the top 97th percentile of
455 holds requested over the past five years.
460 Ratings for records will be displayed in the catalog in the following ways:
462 * On the record result page, the overall average popularity rating is displayed with a label of _Popularity_.
464 * On the record detail page, each individual badge earned by the record is
465 displayed with its rating.
469 * **OPAC Default Sort (opac.default_sort)**: Identifies the default sort method
470 to be used in the catlaog.
472 * **Maximum popularity importance multiplier for popularity-adjusted relevance
473 searches (search.max_popularity_importance_multiplier):** A multiplier identifying
474 the importance of popularity in the Popularity-Adjusted Relevance ranked
475 searches. The number should be a decimal ranging between 1.0 and 2.0. The
476 default value is 1.1.
478 More detailed information is available in the TechRef docs directory of the
479 Evergreen source code.
484 Removal of Advanced Hold Options link when part holds are expected
485 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
486 If a user attempts to place a metarecord hold when all eligible copies
487 contain parts, the hold will fail. To help prevent the user from reaching
488 a dead end while placing holds, the *Advanced Hold Options* link is removed
489 from the Place Hold page in cases where all copies on the record contain
490 parts. The *Advanced Hold Options* link will remain for records that have
491 a mix of parted and non-parted copies.
504 Renewals attempted via SIP will now consider whether a penalty is configured
505 to block renewals before blocking the renewal. Previously, any penalty, even
506 if it wasn't set to block renewals, would prevent a renewal from succeeding
513 Treat SIP Location Field as Login Workstation
514 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
515 When using a version of SIPServer that supports the feature,
516 the Location (CP) field of the Login (93) message will be
517 used as the workstation name if supplied. Blank or missing
518 location fields will be ignored. This allows users or reports
519 to determine which selfcheck performed a circulation.
532 Translations in this release have been significantly increased. In
533 particular, Spanish has received a huge update with over 9,000 new
534 translations, Czech has received a sizeable update of over 800
535 translations, and additional smaller updates have been added for
536 Arabic, French (Canada), and Armenian.
540 2.11.0 Acknowledgments
541 ----------------------
542 The Evergreen project would like to acknowledge the following
543 organizations that commissioned developments in this release of
547 * Georgia Public Library Service
549 * Pennsylvania Integrated Library System
550 * Pioneer Library System
552 We would also like to thank the following individuals who contributed
553 code, management, translations, documentation patches and tests to this
554 release of Evergreen:
574 We also thank the following organizations whose employees contributed
578 * Central/Wester Massachusetts Automated Resource Sharing
579 * Equinox Software, Inc.
580 * Emerald Data Networks, Inc.
582 * Georgia Public Library Serivce
583 * King County Library System
585 * Laurentian University
588 * North of Boston Library Exchange
589 * Traverse Area District Library
591 We regret any omissions. If a contributor has been inadvertantly
592 missed, please open a bug at http://bugs.launchpad.net/evergreen/