Docs: Minor fixes for 2.11 Release Notes
[Evergreen.git] / docs / RELEASE_NOTES_2_11.adoc
1 Evergreen 2.11.0 Release Notes
2 ==============================
3 :toc:
4 :numbered:
5
6 Upgrade notes
7 -------------
8
9
10 Tablefunc Extension No Longer Required
11 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
12 Changes in the behavior of the connectby function in PostgreSQL 9.5
13 have prompted its removal from the database.  It is easier for
14 Evergreen to maintain compatibility with previous versions of
15 PostgreSQL without this function.
16
17 By eliminating the use of the connectby function, we eliminate the
18 requirement for the tablefunc database extension.  It is no longer
19 installed when the database is created.  If you are upgrading and wish
20 to remove it from your database, you may run the following statement
21 in the database to drop it:
22
23  DROP EXTENSION tablefunc;
24
25
26
27
28
29 New Features
30 ------------
31
32
33
34 Administration
35 ~~~~~~~~~~~~~~
36
37
38
39 Add Date Header to Action Trigger Email/SMS Templates
40 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
41 The Date: header specified in RFC 2822 has been added to the seed data
42 for the example Action Trigger email and SMS templates, but no attempt
43 has been made to automatically modify existing templates. To add this
44 header (and end any "Why are my library emails from 1969/70?" questions
45 you may have heard) make sure the following lines are in all templates
46 that use the SendEmail or SendSMS reactors:
47
48 The first is already in most sample templates, but you may need to add
49 it to the top of any custom templates:
50 `[%- USE date -%]`
51
52 And this line should be inserted into the header block of each template:
53 `Date: [%- date.format(date.now, '%a, %d %b %Y %T -0000', gmt => 1) %]`
54
55
56
57
58
59 Support for Ubuntu 16.04
60 ^^^^^^^^^^^^^^^^^^^^^^^^
61 Adds support for Ubuntu Xenial Xerus (16.04).
62
63
64
65
66
67 Purge User Activity
68 ^^^^^^^^^^^^^^^^^^^
69
70 User activity types are now set to transient by default for new
71 Evergreen installs..  This means only the most recent activity entry per
72 user per activity type is retained in the database.
73
74 This change does not affect existing activity types, which were set to
75 non-transient by default.  To make an activity type transient, modify the
76 'Transient' field of the desired type in the staff client under Admin -> 
77 Server Administration -> User Activity Types.
78
79 Setting an activity type to transient means data for a given user will
80 be cleaned up automatically if and when the user performs the activity
81 in question.  However, administrators can also force an activity
82 cleanup via SQL.  This is useful for ensuring that all old activity
83 data is deleted and for controlling when the cleanup occurs, which 
84 may be useulf on very large actor.usr_activity tables.
85
86 To force clean all activity types:
87
88 [source,sql]
89 ------------------------------------------------------------
90 SELECT actor.purge_usr_activity_by_type(etype.id)
91     FROM config.usr_activity_type etype;
92 ------------------------------------------------------------
93
94 NOTE: This could take hours to run on a very large actor.usr_activity table.
95
96
97
98
99
100 Cataloging
101 ~~~~~~~~~~
102
103
104
105 Authority Record Import Updates Editor, Edit Date.
106 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
107 Importing an authority record via MARC Batch Import/Export now causes the 
108 authority record's editor and edit_date fields to be updated.  The editor
109 value may come from the MARC 905u field or, if none is present, the user 
110 performing the import.
111
112
113
114
115 Authority Propagation Updates Bib Editor / Edit Date
116 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
117 When a bib record is automatically updated as a result of the
118 modification of a linked authority record, the bib record's "Last Edit
119 Date/Time" and "Last Editing User" fields will be updated to match the
120 time of the update and the editor of the modified authority record.
121
122 A new global flag is available to control this behavior called
123 'ingest.disable_authority_auto_update_bib_meta' ("Authority Automation:
124 Disable automatic authority updates from modifying bib record editor
125 and edit_date").  When enabled, theses fields will not be updated.  By
126 default, this setting is disabled.
127
128 An additional speed improvement is included in this feature.  No attempt
129 will be made to update linked bib records when the normalized heading of
130 the modified authority record is unchanged by the authority record update.
131
132
133
134
135 Bibliographic Record Source Now Copied to 901$s
136 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
137 If a bibliographic record has a source set, the name of that source
138 is now copied to the 901$s whenever the record is created or updated.
139 This allows the source to be used for record matching and MARC
140 field queries.
141
142
143
144
145 Option to Update Bib Source and Edit Details on Record Import
146 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
147 When importing records through the client, users will now have the ability to
148 define whether the bib source, last editor, and last edit date should be updated
149 on a record merge/overlay.
150
151 In MARC Batch Import / Export, select the _Merge / Overlay_ tab.  Each entry in
152 the table has a value in the new _Update bib. source_ column. If that value is
153 True, then the bib source, last editor, and last edit date will be updated.
154
155 The two system-defined entries have been pre-set to appropriate values (Full
156 Overlay = true; Match-Only Merge = false).
157
158
159
160
161 Circulation
162 ~~~~~~~~~~~
163
164
165
166 Staff Client Honors Aged Circulations
167 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
168
169 The browser and XUL clients now better represent copy checkout history 
170 by honoring and displaying information from aged circulations.  
171
172  * Browser client 'Recent Circ History' and the analogous XUL client 
173    'Circulation History' tabs show summary data for aged circulations
174    as well as regular/active circulations.  When aged circulation data
175    is displayed, any references to patron names are replaced by the string
176    "<Aged Circulation>".
177
178  * Browser client 'Circ History List' and the analogous XUL client 
179    'Last Few Circulations' tabs behave as above, plus their 'Add 
180    Billing' buttons are disabled when displaying aged circulation data.
181
182  * XUL client 'Retrieve Last Patron' actions from various UI's report, 
183    "Item XXX circulation is an aged circulation and has no linked user".
184    Browser client analog uses 'Circ History List' instead; no additional
185    changes required.
186
187
188
189
190
191 "Canceled Transit" Item Status
192 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
193
194 Previously, when a transit was aborted, the transited item would either go into
195 "Reshelving" status or would return to whatever status it was in when it went
196 into transit, even when the item itself was in a different status (including
197 "Checked out").  Now, for most transits that get aborted, the item is put into a 
198 new status, "Canceled Transit", which signals to staff the actual state of the
199 item.  This feature only affects items with a status of "In transit" and does
200 not affect items that were in the following statuses at the time they were sent
201 into transit:
202
203 * Bindery
204 * Lost
205 * Missing
206 * On order
207 * ILL
208 * Damaged
209 * Long Overdue
210 * Lost and Paid
211 * Any custom statuses
212
213 This change should help clear up confusing situations caused by the previous
214 "abort transit" behavior, such as items showing "Available" when they are actually
215 en route, and patrons' items mysteriously disappearing from their accounts and
216 showing "Available" at the item-owning library without evidence of check-in.
217
218
219
220
221 Copy Status "Is Available" Flag
222 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
223
224 A new boolean field is now available for copy statuses to indicate when copies
225 having a given status should be considered available.  The field has 2 main
226 effects:
227
228 1. Checking out an "available" copy will no longer result in an override-able
229    "COPY_NOT_AVAILABLE" alert for staff.  The copy will checkout without 
230    status warnings.
231
232 2. "Available" copies will appear in catalog searches where "limit to
233    available" is selected as a search filter.
234
235 By default, the "Available" and "Reshelving" statuses have the "Is Available" 
236 flag set.  The flag may be applied to local/custom statuses via the copy
237 status admin interface.
238
239
240
241
242
243 Email Checkout Receipts
244 ^^^^^^^^^^^^^^^^^^^^^^^
245 This feature allows patrons to receive checkout receipts through email
246 at the circulation desk and in the Evergreen self-checkout interface.
247 Patrons need to opt in to receive email receipts by default and must
248 have an email address associated with their account. Opt in can be staff
249 mediated at the time of account creation or in existing accounts.
250 Patrons can also opt in directly in their OPAC account or through patron
251 self-registration. This feature does not affect the behavior of
252 checkouts from SIP2 devices.
253
254 Patrons can opt in to receive email checkout receipts by default via
255 a new _Email checkout reciepts by default_ patron setting.
256
257 This feature also enhances the patron staging tables so that patron
258 settings can be chosen during self-registration.
259
260 The web staff interface's checkout screen now includes a "Quick
261 Receipt" button that allows staff members to generate a receipt
262 at any time.
263
264
265
266
267 Set Per-OU Limits on Allowed Payment Amounts
268 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
269 Two new settings have been added to prevent clerks from accidentally clearing
270 all patron bills by scanning a barcode into the Payment Amount field, or
271 accidentally entering the amount without a decimal point (such as you
272 would when using a cash register).
273
274 Both settings are available via the Library Settings Editor. The _Payment
275 amount threshold for Are You Sure? dialog_ (ui.circ.billing.amount_warn)
276 setting identifies the amount above
277 which staff will be asked if they're sure they want to apply the payment.
278 The _Maximum payment amount allowed_ (ui.circ.billing.amount_limit)
279 setting identifies the maximum amount of
280 money that can be accepted through the staff client.
281
282 These settings only effect the staff client, not credit
283 cards accepted through the OPAC, or direct API calls
284 from third party tools.
285
286
287
288
289 Client
290 ~~~~~~
291
292
293
294 Additional Fields Available for Display in Some Interfaces
295 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
296 The holds age protection field will now be available for display in the
297 following interfaces:
298
299 * Item status list view column picker
300 * Item status alternate view
301 * Holdings maintenance column picker
302
303 The asset.copy.cost field, which records the amount paid for an item when
304 an invoice is processed, will be available for display in the following
305 interfaces:
306
307 * Items status list view column picker
308 * Item status alternate view
309 * Copy editor
310
311
312
313
314
315 OPAC
316 ~~~~
317
318
319
320 Merge Notification Preferences Tables in TPAC
321 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
322 The patron notification preference page in the public catalog
323 used to have two tables, separating notification settings
324 based on their source. Since that distinction does not matter
325 to patrons, and since the two tables aren't styled consistently,
326 they are merged together.
327
328
329
330
331 Improved Holds Screens in My Account
332 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
333 The grids in the My Account _Items on Hold_ and _Holds History_ interfaces are
334 simplified. Data previously contained in their own Activate, Active, and Date
335 Fulfilled columns are now incorporated into the Status column. To further
336 declutter the interface, the holds queue position will only show when the user
337 most needs the information - before the hold has been captured. 
338
339 Distinct CSS classes have also been added for each hold status and each date
340 that could potentially display in these holds interfaces. A new default style
341 highlights the _Available_ status in green and the _Suspended_ status
342 in red.
343
344
345
346
347
348
349 Popularity Boost for Ranking Search Results
350 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
351
352 This feature uses factors such as  circulation and hold activity, record and item age, and item ownership counts to generate popularity badges for bibliographic
353 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. 
354
355 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.
356
357 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.
358
359 Finally, there will continue to be a pure _Relevance_ sort option, which is the version that exists today.
360
361 Administrators can comment out one of the available sort methods by editing the
362 filtersort.tt2 file.A global flag will allow Evergreen sites to select a default sort method.
363
364 Badge Configuration
365 +++++++++++++++++++
366
367 Administrative interfaces to configure badges are only available in the web
368 client. Administrators can also configure badges directly via the database.     
369
370 Available Popluarity Parameters available for badges include:
371
372 * Holds Filled Over Time
373 * Holds Requested Over Time
374 * Current Hold Count
375 * Circulations Over Time
376 * Current Circulation Count
377 * Out/Total Ratio
378 * Holds/Total Ratio
379 * Holds/Holdable Ratio
380 * Percent of Time Circulating
381 * Bibliographic Record Age (days)
382 * Publication Age (days)
383 * Available On-Line (for e-books, etc)
384 * Copy Count
385
386 Badges can be configured to apply to a targeted group of bibliographic records
387 based on the following available filters:
388
389 * Record attribute
390 * Bibliographic source
391 * Circulation modifier
392 * Copy location group
393
394 Badges can also be be restricted to materials owned by a specific organiztional
395 unit.
396
397 This new feature comes with a starter badge based on the top 97th percentile of
398 holds requested over the past five years.
399
400 Display in the OPAC
401 +++++++++++++++++++
402
403 Ratings for records will be displayed in the catalog in the following ways:
404
405 * On the record result page, the overall average popularity rating is displayed with a label of _Popularity_.
406
407 * On the record detail page, each individual badge earned by the record is
408 displayed with its rating. 
409
410 New Global Flags
411 ++++++++++++++++
412 * **OPAC Default Sort (opac.default_sort)**: Identifies the default sort method
413 to be used in the catlaog.
414
415 * **Maximum popularity importance multiplier for popularity-adjusted relevance
416 searches (search.max_popularity_importance_multiplier):** A multiplier identifying
417 the importance of popularity in the Popularity-Adjusted Relevance ranked 
418 searches. The number should be a decimal ranging between 1.0 and 2.0. The
419 default value is 1.1.
420
421 More detailed information is available in the TechRef docs directory of the
422 Evergreen source code.
423
424
425
426
427 Removal of Advanced Hold Options link when part holds are expected
428 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
429 If a user attempts to place a metarecord hold when all eligible copies
430 contain parts, the hold will fail. To help prevent the user from reaching
431 a dead end while placing holds, the *Advanced Hold Options* link is removed
432 from the Place Hold page in cases where all copies on the record contain
433 parts. The *Advanced Hold Options* link will remain for records that have
434 a mix of parted and non-parted copies.
435
436
437
438
439
440 SIP
441 ~~~
442
443
444
445 SIP Renewals
446 ^^^^^^^^^^^^^
447 Renewals attempted via SIP will now consider whether a penalty is configured
448 to block renewals before blocking the renewal. Previously, any penalty, even
449 if it wasn't set to block renewals, would prevent a renewal from succeeding
450 via SIP. 
451
452
453
454
455
456 Treat SIP Location Field as Login Workstation
457 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
458 When using a version of SIPServer that supports the feature,
459 the Location (CP) field of the Login (93) message will be
460 used as the workstation name if supplied. Blank or missing
461 location fields will be ignored. This allows users or reports
462 to determine which selfcheck performed a circulation.
463
464
465
466
467
468 Translations
469 ~~~~~~~~~~~~
470
471
472
473 Translation Updates
474 ^^^^^^^^^^^^^^^^^^^
475 Translations in this release have been significantly increased.  In
476 particular, Spanish has received a huge update with over 9,000 new
477 translations, Czech has received a sizeable update of over 800
478 translations, and additional smaller updates have been added for
479 Arabic, French (Canada), and Armenian.
480
481
482
483 Acknowledgments
484 ---------------
485 The Evergreen project would like to acknowledge the following
486 organizations that commissioned developments in this release of
487 Evergreen:
488
489  * Bibliomation
490  * Georgia Public Library Service
491  * MassLNC
492  * Pennsylvania Integrated Library System
493  * Pioneer Library System
494
495 We would also like to thank the following individuals who contributed
496 code, management, translations, documentation patches and tests to this
497 release of Evergreen:
498
499  * Jason Boyer
500  * Eva Cerninakova
501  * Galen Charlton
502  * Bill Erickson
503  * Blake Henderson
504  * Jeff Godin
505  * Kathy Lussier
506  * Michele Morgan
507  * Dan Pearl
508  * Dan Scott
509  * Chris Sharp
510  * Ben Shum
511  * Mike Rylander
512  * Jason Stephenson
513  * Anahi Valdez
514  * Dan Wells
515
516
517 We also thank the following organizations whose employees contributed
518 patches:
519
520  * Calvin College
521  * Central/Wester Massachusetts Automated Resource Sharing
522  * Equinox Software, Inc.
523  * Emerald Data Networks, Inc.
524  * Evergreen Indiana
525  * Georgia Public Library Serivce
526  * King County Library System
527  * Knihovna Jabok
528  * Laurentian University
529  * MassLNC
530  * MOBIUS
531  * North of Boston Library Exchange
532  * Traverse Area District Library
533
534 We regret any omissions.  If a contributor has been inadvertantly
535 missed, please open a bug at http://bugs.launchpad.net/evergreen/
536 with a correction.
537