1880cec581186f65b432da3398731420530ab835
[Evergreen.git] / docs / RELEASE_NOTES_3_2.adoc
1 Evergreen 3.2 Release Notes
2 ===========================
3 :toc:
4 :numbered:
5
6 Evergreen 3.2.1
7 ----------------
8 This release contains bug fixes improving on Evergreen 3.2.0.
9
10 Bug fixes
11 ~~~~~~~~~
12
13 * Adds several columns to the items out grid.
14 * Adds the ability to copy patron addresses to the clipboard.
15 * Fixes several issues with adding new items and call numbers.
16 * Adds links to catalog records from the query and pending tabs of the Record Buckets interface.
17 * Corrects the date format used in several bucket interfaces.
18 * The new Angular 6 interfaces now use the correct favicon.
19
20 Acknowledgements
21 ~~~~~~~~~~~~~~~~
22 We would like to thank the following individuals who contributed code,
23 tests and documentation patches to the 3.2.1 point release of
24 Evergreen:
25
26 * John Amundson
27 * a. bellenir
28 * Galen Charlton
29 * Garry Collum
30 * Dawn Dale
31 * Bill Erickson
32 * Kathy Lussier
33 * Mike Rylander
34 * Jane Sandberg
35 * Jason Stephenson
36 * Cesar Velez
37 * Dan Wells
38
39
40 3.2.0 Upgrade notes
41 -------------------
42
43 Disabling of Legacy XUL Staff Client
44 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
45 The legacy XUL staff client is no longer supported in Evergreen
46 3.2.x and the server-side installation no longer supports a
47 direct connection by a version XUL client by default.  *All
48 users of Evergreen 3.2.x are strongly urged to complete their
49 switch to the web staff client as part of upgrading to 3.2.x.*
50
51 Evergreen administrators who for some reason continue to wish
52 to deploy the XUL staff client can do so at their risk by
53 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
54 and using `make_release` to create installers for the staff client.
55 However, no community support will be provided for the XUL client.
56
57
58
59 Acq Invoice Reports
60 ~~~~~~~~~~~~~~~~~~~
61
62 Existing Acquisitions report templates that reference the invoice 'complete'
63 field should be modified to check whether the new close_date field is NOT NULL
64 instead.
65
66 At deploy time, all invoices with a 'complete' value of TRUE will have their
67 'close_date' field set to NOW.  A value is required, since this field is
68 now the source of whether an invoice is open or closed.
69
70 However, no values will be applied to the closed_by field for already closed
71 invoices.
72
73
74 Angular6 Base Application
75 ~~~~~~~~~~~~~~~~~~~~~~~~~
76
77 System Admin Upgrade Notes
78 ^^^^^^^^^^^^^^^^^^^^^^^^^^
79
80 Like the AngularJS application, Evergreen releases will come with all
81 web browser staff client code pre-compiled.  Admins only need to add an
82 Apache configuration change.
83
84 Add the following stanza to /etc/apache2/eg_vhost.conf.
85
86 [source,conf]
87 --------------------------------------------------------------------------
88 RewriteCond %{REQUEST_URI}  ^/eg2/
89 RewriteCond %{REQUEST_URI}  !^/eg2/([a-z]{2}-[A-Z]{2})/
90 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
91
92 <Directory "/openils/var/web/eg2/en-US">
93     FallbackResource /eg2/en-US/index.html
94 </Directory>
95 --------------------------------------------------------------------------
96
97 For multi-locale sites, see the bottom section of
98 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
99 configuration.  The section starts with "/eg2/ client setup and locale
100 configuration"
101
102 Developer Upgrade Notes
103 ^^^^^^^^^^^^^^^^^^^^^^^
104
105 Developers building Angular code on existing installations need to update
106 their version of NodeJS by re-running the -developer prereqs installer.
107
108 [source,sh]
109 --------------------------------------------------------------------------
110 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
111 --------------------------------------------------------------------------
112
113
114 Asynchronous Vandelay Imports
115 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
116
117 Users of NGINX as a reverse proxy may need to set a suitable
118 `client_max_body_size` value in the NGINX configuration so that large
119 MARC record uploads are not truncated. Note that this would have
120 always been necessary, but since this feature allows larger files
121 to be more reliably queued and imported, the need to set `client_max_body_size`
122 became more apparent.
123
124
125 Browser Client Settings & Preferences Stored on the Server
126 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
127
128 A new permission APPLY_WORKSTATION_SETTING has been added to control who
129 may apply values to workstation settings.  Use something like the following
130 to apply the permission to all staff accounts (mileage may vary):
131
132 [source,sh]
133 --------------------------------------------------------------------------
134 INSERT INTO permission.grp_perm_map (grp, perm, depth)
135 VALUES (
136     (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
137     (SELECT id FROM permission.perm_list WHERE code =
138 'APPLY_WORKSTATION_SETTING'),
139     0 -- or 1, 2, etc.
140 );
141 --------------------------------------------------------------------------
142
143 Workstation setting types matching values previously stored in the browser
144 (via localStorage or Hatch) are created as part of this feature.  During
145 upgrade, admins should consider whether any of these new setting types
146 should be transferred to user and/or org unit settings instead.  Setting
147 type changes can be made at any time, but when a setting type is deleted
148 all of its data is deleted, so a change in type means re-applying the
149 settings in the browser client.
150
151 Values stored in the browser will automatically migrate to server settings
152 as each setting is accessed in the browser client.  Once migrated, the
153 in-browser copies are deleted.
154
155 If a setting type does not exist where the browser expects one, the
156 value is stored in-browser instead and a warning is issued in the console.
157
158
159
160
161 3.2.0 New Features
162 ------------------
163
164
165 Acquisitions
166 ~~~~~~~~~~~~
167
168 Auto-Cancel Line items When All Copies Are Canceled
169 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
170 When a copy (line item detail) is canceled through the Acquisitions interface, 
171 the parent line item is also canceled if all copies for that line item are also 
172 canceled.  The cancel reason given will come from:
173
174 . The cancel reason for the just-canceled copy if it's a Keep Debits true 
175 cancel reason.
176 . The cancel reason from any other copy on the lineitem that has a Keep 
177 Debits true cancel reason.
178 . The cancel reason for the just-canceled copy if no copies have a Keep
179 Debits true cancel reason.
180
181
182 Invoice Closed Date and Closed By Fields
183 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
184 Acquisitions invoices have 2 new fields:
185
186 * Close Date -- This is set to the time when the ACQ user clicks the "Close"
187   button in the invoice interface.
188   ** This field 'replaces' the existing 'complete' field.  An invoice is
189      considered complete if a close date value is set.
190 * Closed By -- This is set to the logged in staff user who performs the 
191   "Close" action.
192
193 As with the now-defunct 'complete' field, but new fields are cleared in the 
194 event an invoice is reopened.
195
196 These new fields are visible in the invoice interface under the 
197 'Show Details' action for closed invoices.
198
199 Upgrading Invoice Reports
200 +++++++++++++++++++++++++
201
202 Existing report templates that reference the invoice 'complete' field 
203 should be modified to check whether the new close_date field is NOT NULL
204 instead.
205
206 Other Upgrade Considerations
207 ++++++++++++++++++++++++++++
208
209 At deploy time, all invoices with a 'complete' value of TRUE will have their
210 'close_date' field set to NOW.  A value is required, since this field is
211 now the source of whether an invoice is open or closed.
212
213 However, no values will be applied to the closed_by field for already closed
214 invoices.
215
216
217
218 Patron Acquisitions Requests
219 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
220
221 The existing interface for staff-mediated patron acquisition requests has been replaced in the web staff client with a re-implementation written in AngularJS, with some minor bug fixes (including access from the Patron interface) and other improvements.
222
223
224
225 Administration
226 ~~~~~~~~~~~~~~
227
228 Hold Targeter Script has been Replaced
229 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
230
231 The original hold_targeter.pl script has been renamed to
232 "hold_targeter_legacy.pl", and the new-style hold targeting
233 script has been renamed to "hold_targeter.pl".  Administrators
234 will want to change their crontab files to reflect this.
235
236 .Previous Syntax
237 [source,bash]
238 ---------------------------------------------------------------------
239 -*/15 * * * *   . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl $SRF_CORE
240 ---------------------------------------------------------------------
241
242 .New Syntax
243 [source,bash]
244 -----------------------------------------------------------------------------------
245 -*/15 * * * *   . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl --osrf-config
246 $SRF_CORE
247 -----------------------------------------------------------------------------------
248
249 The sample crontab file at `Open-ILS/examples/crontab.example` reflects
250 this change.
251
252
253
254 Architecture
255 ~~~~~~~~~~~~
256
257 Angular6 Base Application
258 ^^^^^^^^^^^^^^^^^^^^^^^^^
259 With Evergreen 3.2, we introduce the initial infrastructure for
260 migrating to a new version of Angular.  The structure of the new code
261 is quite different from the AngularJS code and it runs as a separate
262 application which communicates with the AngularJS app via shared storage
263 and in-page URLs that link back and forth between the two.
264
265 For this release, users will only be directed to the new Angular site
266 when navigating to Administration => Acquisitions Administration.  Once
267 on this page, some of the admin interfaces will presented as Angular6
268 interfaces, while others will direct users back to the AngularJS
269 application.  The Angular6 interfaces are the simpler, grid-based
270 interfaces.
271
272 Acquisitions Admin Angular6 Interfaces
273 ++++++++++++++++++++++++++++++++++++++
274
275  * Cancel Reasons
276  * Claim Event Types
277  * Claim Policies
278  * Claim Policy Actions
279  * Claim Types
280  * Currency Types
281  * EDI Accounts
282  * EDI Messages
283  * Exchange Rates
284  * Fund Tags
285  * Invoice Item Types
286  * Invoice Payment Method
287  * Line Item Alerts
288  * Line Item MARC Attribute Definitions
289
290 System Admin Upgrade Notes
291 ++++++++++++++++++++++++++
292
293 Like the AngularJS application, Evergreen releases will come with all
294 web browser staff client code pre-compiled.  Admins only need to add an
295 Apache configuration change.
296
297 Add the following stanza to /etc/apache2/eg_vhost.conf.
298
299 [source,conf]
300 --------------------------------------------------------------------------
301 RewriteCond %{REQUEST_URI}  ^/eg2/
302 RewriteCond %{REQUEST_URI}  !^/eg2/([a-z]{2}-[A-Z]{2})/
303 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
304
305 <Directory "/openils/var/web/eg2/en-US">                                       
306     FallbackResource /eg2/en-US/index.html                                     
307 </Directory>  
308 --------------------------------------------------------------------------
309
310 For multi-locale sites, see the bottom section of
311 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
312 configuration.  The section starts with "/eg2/ client setup and locale
313 configuration"
314
315 Developer Upgrade Notes
316 +++++++++++++++++++++++
317
318 Developers building Angular code on existing installations need to update 
319 their version of NodeJS by re-running the -developer prereqs installer.
320
321 [source,sh]
322 --------------------------------------------------------------------------
323 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
324 --------------------------------------------------------------------------
325
326
327 Cataloging
328 ~~~~~~~~~~
329
330 Add UPC to z39.50 search for OCLC and LOC
331 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
332 Add UPC as a search attribute for both OCLC and LOC targets in
333 z39.50 for cataloging.
334
335
336 Asynchronous Vandelay Imports
337 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
338
339 Vandelay imports are now monitored from the browser client asynchronously,
340 meaning the client requests updates from the server instead of waiting for 
341 the server to respond to the original import request.  This changes allows 
342 for incremental progress updates in the browser client.
343
344 New Database Table
345 ++++++++++++++++++
346
347 This adds a new database table vandelay.session_tracker for tracking
348 in-progress vandelay upload activity.  A new tracker row is added for
349 each of "upload", "enqueue", and "import" actions, linked for a given
350 session by the value stored in the "session_key" field.
351
352 The table tracks other potentially useful data, like the staff member
353 and workstation where the action was performed.
354
355 Upgrade notes
356 +++++++++++++
357 Users of NGINX as a reverse proxy may need to set a suitable
358 `client_max_body_size` value in the NGINX configuration so that large
359 MARC record uploads are not truncated. Note that this would have
360 always been necessary, but since this feature allows larger files
361 to be more reliably queued and imported, the need to set `client_max_body_size`
362 became more apparent.
363
364
365
366
367 Support for Last Inventory Date
368 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
369 Evergreen now provides an option to add an inventory date to items to facilitate
370 the process of performing inventory in libraries. Staff can add an inventory
371 date to an item in one of the following ways:
372  * From the check in screen, there is now an Update Inventory check in modifier.
373 When selected, scanned barcodes will have the current date/time added as the
374 inventory date while the item is checked in.
375  * From the Item Status screen, an action is available to add the current 
376 date/time as the inventory date to selected items.
377
378 This new feature will also store the workstation that was used when the
379 inventory date was updated.
380
381
382
383 Parallel Ingest with pingest.pl
384 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
385 A program named pingest.pl is now installed to allow faster bibliographic record
386 ingest.  It performs ingest in parallel so that multiple batches can
387 be done simultaneously.  It operates by splitting the records to be
388 ingested up into batches and running all of the ingest methods on each
389 batch.  You may pass in options to control how many batches are run at
390 the same time, how many records there are per batch, and which ingest
391 operations to skip.
392
393 NOTE: The browse ingest is presently done in a single process over all
394 of the input records as it cannot run in parallel with itself.  It
395 does, however, run in parallel with the other ingests.
396
397 Command Line Options
398 ++++++++++++++++++++
399 pingest.pl accepts the following command line options:
400
401 --host::
402     The server where PostgreSQL runs (either host name or IP address).
403     The default is read from the PGHOST environment variable or
404     "localhost."
405
406 --port::
407     The port that PostgreSQL listens to on host.  The default is read
408     from the PGPORT environment variable or 5432.
409
410 --db::
411     The database to connect to on the host.  The default is read from
412     the PGDATABASE environment variable or "evergreen."
413
414 --user::
415     The username for database connections.  The default is read from
416     the PGUSER environment variable or "evergreen."
417
418 --password::
419     The password for database connections.  The default is read from
420     the PGPASSWORD environment variable or "evergreen."
421
422 --batch-size::
423     Number of records to process per batch.  The default is 10,000.
424
425 --max-child::
426     Max number of worker processes (i.e. the number of batches to
427     process simultaneously).  The default is 8.
428
429 --skip-browse::
430 --skip-attrs::
431 --skip-search::
432 --skip-facets::
433 --skip-display::
434     Skip the selected reingest component.
435
436 --start-id::
437     Start processing at this record ID.
438
439 --end-id::
440     Stop processing when this record ID is reached.
441
442 --pipe::
443     Read record IDs to reingest from standard input.  This option
444     conflicts with --start-id and/or --end-id.
445
446 --max-duration::
447     Stop processing after this many total seconds have passed.  The
448     default is to run until all records have been processed.
449
450 --help::
451     Show the help text.
452
453
454
455 View Authority Record by Database ID
456 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
457
458 A new interface allows catalogers to retrieve a specific
459 authority record using its database ID.  Catalogers can
460 find those IDs in subfield $0 of matching fields in
461 bibliographic records.
462
463 To use the new authority record viewer:
464
465 . Click *Cataloging -> Retrieve Authority Record by ID*.
466 . Type in the ID number of the authority record you are
467 interested in. Don't include any prefixes, just the ID
468 number.
469 . Click *Submit*.
470 . View or edit the authority record as needed.
471
472
473
474 Circulation
475 ~~~~~~~~~~~
476
477
478
479 Autorenewal of Loans
480 ^^^^^^^^^^^^^^^^^^^^
481 Circulation policies in Evergreen can now be configured to automatically renew
482 certain items checked out on patron accounts. Circulations will be renewed
483 automatically up to a custom limit (the `max_auto_renewal` field) and patrons
484 will not need to log in to their OPAC accounts or ask library staff to manually
485 renew materials.
486
487 Two new action triggers have been added to Evergreen that permit the Auto-Renew
488 feature. They can be found, configured, and enabled in Administration>Local
489 Administration>Notifications/Action Triggers. They are named **Autorenew** and
490 **AutorenewNotify**.
491
492 The **Autorenew** A/T definition uses the `checkout.due` hook to automatically
493 validate and renew (in the reactor) circulations on the day they are due,
494 grouped by user. The output events of this definition is is the input used by
495 the related **AutorenewNotify** A/T that simply uses a new hook called
496 `autorenewal` to notify patrons via email of their currently due or
497 auto-renewed items.
498
499 In the webstaff's Patron Items Out page, the new column `AutoRenewalsRemaining`
500 indicates how many autorenewals are available for a particular circulation.
501
502
503
504
505
506 Emergency Closing Handler
507 ^^^^^^^^^^^^^^^^^^^^^^^^
508
509 Staff are provided with interfaces and mechanisms to create library closings
510 that, in addition to affecting future circulation and booking due dates, and
511 hold shelf expirations, will automatically move existing circulation and booking
512 due dates and hold shelf expiration times. This new functionality is
513 conceptually described as Emergency Closings and business logic implementing it
514 as the Emergency Closing Handler. It contains additions and adjustments to the
515 user interface, business logic, and database layers. Access to this
516 functionality is available through the Closed Dates Editor interface in the
517 staff client which has been ported to AngularJS.
518
519 Overview
520 ++++++++
521
522 This development has created new business logic code to inspect, in real time,
523 existing circulation, booking, and hold records, and modify such date and time
524 stamps so that the circulation, booking, or hold will end in the same state it
525 would have if the closing had existed at the time the circulation or booking
526 occurred, or the hold was placed and captured. Of specific note, hourly loans
527 will have their due date adjusted to be the end of the day following the
528 closing.
529
530 When the Emergency Closing is saved, any fines accrued during the closing may be
531 voided, as settings dictate, with the exception of circulations that have been
532 marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE
533 circulations with due dates that fall within the Emergency Closing, no fine
534 adjustment will be applied. Emergency Closing processing is permanent, and
535 cannot be rolled back.
536
537 This functionality is explicitly initiated by staff action. If staff do not
538 request an Emergency Closing, existing circulations, bookings, and holds will
539 not be processed and adjusted. However, if staff request any Closing that starts
540 nearer in time than the length of the longest circulation duration configured
541 for use in the Evergreen instance they will be prompted with the option to
542 create the closing as an Emergency Closing.
543
544 Action/Trigger hooks have been created for circulations and bookings that are
545 adjusted by the Emergency Closing Handler. These will facilitate the creation of
546 notifications to patrons that the due date has changed and to alert them to
547 potential changes in accrued fines.
548
549 Booking start dates are explicitly ignored in this implementation. Because an
550 Emergency Closing is, by its nature, an unexpected event, it will be up to staff
551 to address any bookings which intersect with a new Emergency Closings. Reports
552 can be used to identify booking start dates that overlap with a closing and that
553 may require staff intervention.
554
555 Staff requesting and Emergency Closing must have the new EMERGENCY_CLOSING
556 permission.  Some text describing the feature.
557
558
559
560
561
562 Patron Preferred Name and Name Search Keywords
563 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
564
565 Preferred Name
566 ++++++++++++++
567
568 Adds a new set of patron preferred name fields for prefix, first,
569 middle, last, and suffix allowing patrons to provide preferred name
570 information.  Preferred names are optional and each acts as an overlay
571 to the analogous primary name field, making it possible to provide
572 preferred name values for individual fields.
573
574 For example, a patron named William Erickson may have a preferred first
575 name (pref_first_given_name) of Bill, in which case the preferred name
576 would be Bill Erickson.  Note a preferred last name is not required in
577 this case as the code uses primary name values as defaults when not
578 replaced with a preferred version.
579
580 * Patrons will see primary names displayed in the catalog when set.
581 * Staff will see both primary name and preferred name in the patron
582   summary side bar.
583 * Patron searches for any given name field will search both the primary
584   and preferred name data.
585 * Preferred name fields are available in Action/Trigger templates and
586   are present in various patron-focused print templates.
587
588 Name Keywords
589 ++++++++++++++
590
591 Adds a new field to store miscellaneous patron name search terms.  These
592 values are only for searching and do not appear in any interfaces, apart
593 from the patron summary side bar and the patron edit UI.
594
595 Included is a new search field in the patron search UI which searches
596 keyword values and all other name fields.  It's essentially a global patron
597 name keyword search.
598
599
600
601
602 Client
603 ~~~~~~
604
605 Disabling of legacy XUL staff client
606 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
607 The legacy XUL staff client is no longer supported in Evergreen
608 3.2.x and the server-side installation no longer supports a
609 direct connection by a version XUL client by default.  All
610 users of Evergreen 3.2.x are strongly urged to complete their
611 switch to the web staff client as part of upgrading to 3.2.x.
612
613 Evergreen administrators who for some reason continue to wish
614 to deploy the XUL staff client can do so at their risk by
615 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
616 and using `make_release` to create installers for the staff client.
617 However, no community support will be provided for the XUL client.
618
619
620
621
622 Permission Group Display Entries
623 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
624 In some cases, it is useful to have the ability to reorder permission, or to make
625 only specific groups available in the permission group selector for specific
626 Org Units. An interface has been made available to allow this.
627
628 Group Tree Display Entry Interface
629 ++++++++++++++++++++++++++++++++++
630
631 Permission Group Display Entries can be reordered, added, or removed via
632 _Administration -> Local Admin -> Permission Tree Display Entries_.
633 Select the Org Unit you wish to edit the entries in.
634
635 Entries may be added using the Add functionality, creating entries based
636 on permission groups that have not been added to the tree for the Org
637 Unit you wish to add them to.
638
639 image::media/pgtde_01.png[Group Tree Display Entry Admin UI]
640
641 Moving an Entry
642 +++++++++++++++
643 Moving an entry will shift its position up or down in the patron profile
644 selector for a given Org Unit.
645
646 * Select an entry
647 * Press either the *Move Up* or *Move Down* button. The entry will be 
648 moved up or down, accordingly.
649 * Click *Save* to save your edits.  
650
651 NOTE: You may only move up or down entries that have sibling entries.
652
653 Removing an Entry
654 +++++++++++++++++
655 If you want a particular Org Unit to not have access to specific
656 entries, you may remove an entry. Removing an entry will remove it from 
657 view. The entry will be removed from the database.
658
659 * Select an entry and press the *Remove* button.
660
661 Adding an Entry
662 +++++++++++++++
663 You may add entries from permission groups that are not currently
664 reflected in the permission group tree. This is useful for moving 
665 entries to different parents, or making them root entries.
666
667 image::media/pgtde_02.png[Add Entry modal]
668
669 * If desired, select an entry to be used as the parent entry. 
670 * Press the *Add* button. 
671 * Select a permission group from the dropdown.
672 * If you've selected a parent entry, you may check the *Add Root Entry*
673 box to override that parent and add the entry on the root level. 
674 * If you did not select a parent entry, the entry will be added on the root 
675 level of the tree.
676
677
678
679 Browser Client Settings & Preferences Stored on the Server
680 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
681 Browser client settings and preferences that should persist over time are
682 now stored as settings on the server.  This allows settings to follow
683 users and workstations and reduces problems associated with losing settings 
684 as a result of clearing browser data.
685
686 The browser client honors setting values stored as user settings, workstation
687 settings, and org unit settings, depending on which setting types are
688 locally configured.
689
690 Setting Types
691 +++++++++++++
692
693 * No setting can be both a user and workstation setting.  They are mutually
694   exclusive.
695 * Any setting can be an org unit setting in addition to being a user or
696   workstation setting.
697
698 Read-Only Settings
699 ++++++++++++++++++
700
701 Read-only settings are useful for defining values that staff can use but
702 not modify.  For example, admins may wish to prevent users from locally
703 modifying the grid configuration for a given interface so it remains
704 consistent for all users.
705
706 A setting is read-only when an org unit setting type exists (regardless of 
707 whether a value is applied) and no user or workstation setting type exists.
708
709 Server-Stored Workstation Settings Workstation Admin View
710 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
711
712 There's a new "Server Workstation Prefs" tab to the stored preferences
713 workstation admin interface.  From here, users can view which
714 preferences are stored as server-stored workstation preferences and
715 delete select values.
716
717 Upgrade Notes
718 +++++++++++++
719
720 A new permission APPLY_WORKSTATION_SETTING has been added to control who
721 may apply values to workstation settings.  Use something like the following
722 to apply the permission to all staff accounts (mileage may vary):
723
724 [source,sh]
725 --------------------------------------------------------------------------
726 INSERT INTO permission.grp_perm_map (grp, perm, depth) 
727 VALUES (
728     (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
729     (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
730     0 -- or 1, 2, etc.
731 );
732 --------------------------------------------------------------------------
733
734 Workstation setting types matching values previously stored in the browser
735 (via localStorage or Hatch) are created as part of this feature.  During
736 upgrade, admins should consider whether any of these new setting types 
737 should be transferred to user and/or org unit settings instead.  Setting
738 type changes can be made at any time, but when a setting type is deleted
739 all of its data is deleted, so a change in type means re-applying the 
740 settings in the browser client.
741
742 Values stored in the browser will automatically migrate to server settings
743 as each setting is accessed in the browser client.  Once migrated, the
744 in-browser copies are deleted.  
745
746 If a setting type does not exist where the browser expects one, the 
747 value is stored in-browser instead and a warning is issued in the console.
748
749
750 More consistent terminology in the client
751 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
752 Terminology has been updated in the staff client so that we consistently use
753 the same name to describe the same thing. The following updates have been made:
754
755   * The term 'item' is now consistently used to describe the barcoded entity
756 that had been previously been called both an 'item' and a 'copy'. As a result,
757 we now use the terms 'item buckets', 'item tags', and 'item alerts'.
758   * The term 'volume' is no longer used in the client, with the exception of
759 serials, where the term is used to describe serial volumes. The term 'call
760 number' will replace volume in most other places.
761   *'Holdings' is a more general term used to describe a combination of items
762 and call numbers.
763   * The term 'Shelving Location' is used consistently in favor of 'Copy
764 Location.'
765
766
767
768
769 OPAC
770 ~~~~
771
772
773
774 Batch Actions In the Public Catalog
775 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
776 The public catalog now displays checkboxes on the bibliographic and
777 metarecord constituents results pages. Selecting one or more titles
778 by using the checkboxes will dynamically add those title to the
779 temporary list, which is now renamed the cart.
780
781 Above the results lists there is now a bar with a select-all checkbox,
782 a link to the cart management page that also indicates the number of
783 of titles in the cart, and a link to remove from the cart titles that
784 are selected on the currently displayed results page.
785
786 The search bar now includes an icon of a cart and displays the number
787 of titles currently in the cart. Next to that icon is a menu of cart
788 actions.
789
790 The cart actions available are Place Hold, Print Title Details,
791 Email Title Details, Add Cart to Saved List, and Clear Cart. In the
792 web staff client, the cart actions also include Add Cart to Bucket.
793 When an action is selected from this menu, the user is given an
794 opportunity to confirm the action and to optionally empty the cart
795 when the action is complete. The action is applied to all titles
796 in the cart.
797
798 Clicking on the cart icon brings the user to a page listing the
799 titles in the cart. From there, the user can select specific records
800 to request, print, email, add to a list, or remove from the cart.
801
802 The list of actions on the record details page now provides separate
803 links for adding the title to a cart or to a permanent list.
804
805 The permanent list management page in the public catalog now also
806 includes batch print and email actions.
807
808 Additional information
809 ++++++++++++++++++++++
810 * The checkboxes do not display on the metarecord results page, as
811   metarecords currently cannot be put into carts or lists.
812 * The checkboxes are displayed only if JavaScript is enabled. However,
813   users can still add items to the cart and perform batch actions on
814   the cart and on lists.
815 * A template `config.tt2` setting, `ctx.max_cart_size`, can be used to
816   set a soft limit on the number of titles that can be added to the
817   cart. If this limit is reached, checkboxes to add more records to the
818   cart are disabled unless existing titles in the cart are removed
819   first. The default value for this setting is 500.
820
821 Developer notes
822 +++++++++++++++
823
824 This patch adds to the public catalog two routes that return JSON
825 rather than HTML:
826
827 * `GET /eg/opac/api/mylist/add?record=45`
828 * `GET /eg/opac/api/mylist/delete?record=45`
829
830 The JSON response is a hash containing a mylist key pointing to the list
831 of bib IDs of contents of the cart.
832
833 The record parameter can be repeated to allow adding or removing
834 records as an atomic operation. Note that this change also now available
835 to `/eg/opac/mylist/{add,delete}`
836
837 More generally, this adds a way for EGWeb context loaders to specify that
838 a response should be emitted as JSON rather than rendering an HTML
839 page using `Template::Toolkit`.
840
841 Specifically, if the context as munged by the context loader contains
842 a `json_response` key, the contents of that key will to provide a
843 JSON response. The `json_response_cookie` key, if present, can be used
844 to set a cookie as part of the response.
845
846 Template Toolkit processing is bypassed entirely when emitting a JSON
847 response, so the context loader would be entirely responsible for
848 localization of strings in the response meant for direct human
849 consumption.
850
851
852
853
854 New class for searchbar when on the homepage
855 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
856
857 This adds the `.searchbar-home` class to the div that contains the searchbar
858 when on the homepage.  This allows sites to customize the searchbar differently
859 on the homepage than in other places the search bar appears (for example,
860 offering a large, Google-style search bar on the homepage only).
861
862
863 Username Login Hint
864 ^^^^^^^^^^^^^^^^^^^
865 To make customization easier, the username hint on the OPAC login page ("Please
866 include leading zeros...") has been moved to a separate TT2 template.  If you
867 have customized the hint text, you will need to add your modifications to
868 username_hint.tt2.
869
870
871
872 Acknowledgments
873 ---------------
874 The Evergreen project would like to acknowledge the following
875 organizations that commissioned developments in this release of
876 Evergreen:
877
878 * BC Libraries Cooperative
879 * Consortium Of Ohio Libraries
880 * CW MARS
881 * Georgia Public Library Service
882 * Indiana State Library
883 * Lake Agassiz Regrional Library
884 * MassLNC
885 * North Texas Library Consortium
886 * Northwest Regional Library
887 * Pennsylvania Integrated Library System
888 * South Carolina State Library
889
890 We would also like to thank the following individuals who contributed
891 code, translations, documentations patches and tests to this release of
892 Evergreen:
893
894 * Felicia Beaudry
895 * Jason Boyer
896 * Andrea Buntz Neiman
897 * Eva Cerninakova
898 * Galen Charlton
899 * Garry Collum
900 * Jeff Davis
901 * Bill Erickson
902 * Jason Etheridge
903 * Lynn Floyd
904 * Jeff Godin
905 * Blake Graham-Henderson
906 * Francisco J Guel-Mendoza
907 * Kyle Huckins
908 * Mary Jinglewski
909 * Angela Kilsdonk
910 * Kathy Lussier
911 * Katie G. Martin
912 * Jennifer Pringle
913 * Morkor Quarshie
914 * Mike Rylander
915 * Jane Sandberg
916 * Chris Sharp
917 * Ben Shum
918 * Remington Steed
919 * Jason Stephenson
920 * Cesar Velez
921 * Dan Wells
922 * Stephan Woidowski
923
924 We also thank the following organizations whose employees contributed
925 patches:
926
927 * BC Libraries Cooperative
928 * Calvin College
929 * Catalyte
930 * Equinox Open Library Initiative
931 * Government of Manitoba
932 * Kenton County Public Library
933 * King County Library System
934 * Linn-Benton Community College
935 * MassLNC
936 * Sigio
937
938 We regret any omissions.  If a contributor has been inadvertently
939 missed, please open a bug at http://bugs.launchpad.net/evergreen/
940 with a correction.
941