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