LP#1657282: fix redirect of one-hit metarecord searches
[Evergreen.git] / docs / RELEASE_NOTES_2_11.adoc
1 Evergreen 2.11 Release Notes
2 ============================
3 :toc:
4 :numbered:
5
6 Evergreen 2.11.1
7 ----------------
8
9 This release contains several bug fixes improving on Evergreen 2.11.0
10
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
19 setting is enabled.
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 occurred 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 discernible change for users.
36 * A fix to the display of permanent lists in the catalog, which had broken
37 in 2.11.0.
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 * A fix so that when a bib record's fingerprint changes, it gets correctly
43 moved to a different metarecord.
44
45 Acknowledgements
46 ~~~~~~~~~~~~~~~~
47 We would like to thank the following individuals who contributed code,
48 tests and documentation patches to the 2.11.1 point release of
49 Evergreen:
50
51 * Galen Charlton
52 * Bill Erickson
53 * Blake Henderson
54 * Jim Keenan
55 * Kathy Lussier
56 * Christine Morgan
57 * Dan Scott
58 * Ben Shum
59 * Remington Steed
60 * Josh Stompro
61 * Dan Wells
62
63 2.11.0 Upgrade notes
64 --------------------
65
66
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.
73
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:
79
80  DROP EXTENSION tablefunc;
81
82
83
84
85
86 2.11.0 New Features
87 -------------------
88
89
90
91 Administration
92 ~~~~~~~~~~~~~~
93
94
95
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:
104
105 The first is already in most sample templates, but you may need to add
106 it to the top of any custom templates:
107 `[%- USE date -%]`
108
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) %]`
111
112
113
114
115
116 Support for Ubuntu 16.04
117 ^^^^^^^^^^^^^^^^^^^^^^^^
118 Adds support for Ubuntu Xenial Xerus (16.04).
119
120
121
122
123
124 Purge User Activity
125 ^^^^^^^^^^^^^^^^^^^
126
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.
130
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.
135
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 useful on very large actor.usr_activity tables.
142
143 To force clean all activity types:
144
145 [source,sql]
146 ------------------------------------------------------------
147 SELECT actor.purge_usr_activity_by_type(etype.id)
148     FROM config.usr_activity_type etype;
149 ------------------------------------------------------------
150
151 NOTE: This could take hours to run on a very large actor.usr_activity table.
152
153
154
155
156
157 Cataloging
158 ~~~~~~~~~~
159
160
161
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.
168
169
170
171
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.
178
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.
184
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.
188
189
190
191
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
197 field queries.
198
199
200
201
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.
207
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.
211
212 The two system-defined entries have been pre-set to appropriate values (Full
213 Overlay = true; Match-Only Merge = false).
214
215
216
217
218 Circulation
219 ~~~~~~~~~~~
220
221
222
223 Staff Client Honors Aged Circulations
224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
225
226 The browser and XUL clients now better represent copy checkout history 
227 by honoring and displaying information from aged circulations.  
228
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>".
234
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.
238
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
242    changes required.
243
244
245
246
247
248 "Canceled Transit" Item Status
249 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
250
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
258 into transit:
259
260 * Bindery
261 * Lost
262 * Missing
263 * On order
264 * ILL
265 * Damaged
266 * Long Overdue
267 * Lost and Paid
268 * Any custom statuses
269
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.
274
275
276
277
278 Copy Status "Is Available" Flag
279 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
280
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
283 effects:
284
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 
287    status warnings.
288
289 2. "Available" copies will appear in catalog searches where "limit to
290    available" is selected as a search filter.
291
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.
295
296
297
298
299
300 Email Checkout Receipts
301 ^^^^^^^^^^^^^^^^^^^^^^^
302 This feature allows patrons to receive checkout receipts through email
303 at the circulation desk in the web client and in the Evergreen self-checkout
304 interface. Patrons need to opt in to receive
305 email receipts by default and must have an email address associated with their
306  account. Opt in can be staff mediated at the time of account creation or in
307 existing accounts. Patrons can also opt in directly in their OPAC account or
308 through patron self-registration. This feature does not affect the behavior of
309 checkouts from the XUL client or SIP2 devices.
310
311 Patrons can opt in to receive email checkout receipts by default via
312 a new _Email checkout receipts by default_ patron setting.
313
314 This feature also enhances the patron staging tables so that patron
315 settings can be chosen during self-registration.
316
317 The web staff interface's checkout screen now includes a "Quick
318 Receipt" button that allows staff members to generate a receipt
319 at any time.
320
321
322
323
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).
330
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.
338
339 These settings only affect the staff client, not credit
340 cards accepted through the OPAC, or direct API calls
341 from third party tools.
342
343
344
345
346 Client
347 ~~~~~~
348
349
350
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:
355
356 * Item status list view column picker
357 * Item status alternate view
358 * Holdings maintenance column picker
359
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
362 interfaces:
363
364 * Items status list view column picker
365 * Item status alternate view
366 * Copy editor
367
368
369
370
371
372 OPAC
373 ~~~~
374
375
376
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.
384
385
386
387
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. 
395
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
399 in red.
400
401
402
403
404
405
406 Popularity Boost for Ranking Search Results
407 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
408
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. 
411
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 drop-down 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.
413
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.
415
416 Finally, there will continue to be a pure _Relevance_ sort option, which is the version that exists today.
417
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.
420
421 Badge Configuration
422 +++++++++++++++++++
423
424 Administrative interfaces to configure badges are only available in the web
425 client. Administrators can also configure badges directly via the database.     
426
427 Available Popularity Parameters available for badges include:
428
429 * Holds Filled Over Time
430 * Holds Requested Over Time
431 * Current Hold Count
432 * Circulations Over Time
433 * Current Circulation Count
434 * Out/Total Ratio
435 * Holds/Total Ratio
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)
441 * Copy Count
442
443 Badges can be configured to apply to a targeted group of bibliographic records
444 based on the following available filters:
445
446 * Record attribute
447 * Bibliographic source
448 * Circulation modifier
449 * Copy location group
450
451 Badges can also be be restricted to materials owned by a specific organizational
452 unit.
453
454 This new feature comes with a starter badge based on the top 97th percentile of
455 holds requested over the past five years.
456
457 Display in the OPAC
458 +++++++++++++++++++
459
460 Ratings for records will be displayed in the catalog in the following ways:
461
462 * On the record result page, the overall average popularity rating is displayed with a label of _Popularity_.
463
464 * On the record detail page, each individual badge earned by the record is
465 displayed with its rating. 
466
467 New Global Flags
468 ++++++++++++++++
469 * **OPAC Default Sort (opac.default_sort)**: Identifies the default sort method
470 to be used in the catalog.
471
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.
477
478 More detailed information is available in the TechRef docs directory of the
479 Evergreen source code.
480
481
482
483
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.
492
493
494
495
496
497 SIP
498 ~~~
499
500
501
502 SIP Renewals
503 ^^^^^^^^^^^^^
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
507 via SIP. 
508
509
510
511
512
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.
520
521
522
523
524
525 Translations
526 ~~~~~~~~~~~~
527
528
529
530 Translation Updates
531 ^^^^^^^^^^^^^^^^^^^
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 sizable update of over 800
535 translations, and additional smaller updates have been added for
536 Arabic, French (Canada), and Armenian.
537
538
539
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
544 Evergreen:
545
546  * Bibliomation
547  * Georgia Public Library Service
548  * MassLNC
549  * Pennsylvania Integrated Library System
550  * Pioneer Library System
551
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:
555
556  * Jason Boyer
557  * Eva Cerninakova
558  * Galen Charlton
559  * Bill Erickson
560  * Blake Henderson
561  * Jeff Godin
562  * Kathy Lussier
563  * Michele Morgan
564  * Dan Pearl
565  * Dan Scott
566  * Chris Sharp
567  * Ben Shum
568  * Mike Rylander
569  * Jason Stephenson
570  * Anahi Valdez
571  * Dan Wells
572
573
574 We also thank the following organizations whose employees contributed
575 patches:
576
577  * Calvin College
578  * Central/Wester Massachusetts Automated Resource Sharing
579  * Equinox Software, Inc.
580  * Emerald Data Networks, Inc.
581  * Evergreen Indiana
582  * Georgia Public Library Service
583  * King County Library System
584  * Knihovna Jabok
585  * Laurentian University
586  * MassLNC
587  * MOBIUS
588  * North of Boston Library Exchange
589  * Traverse Area District Library
590
591 We regret any omissions.  If a contributor has been inadvertently
592 missed, please open a bug at http://bugs.launchpad.net/evergreen/
593 with a correction.
594