1 Evergreen 3.2 Release Notes
2 ===========================
8 This release contains bug fixes improving on Evergreen 3.2.3.
9 All bug fixes refer to the staff client unless otherwise specified.
17 * Hatch is now deprecated for local data storage. Hatch is
18 still recommended for printing in certain situations.
23 * The new `edi_order_pusher.pl` now only pushes purchase orders
24 with a state of "on-order", to prevent older purchase orders
25 from being unintentionally pushed to vendors.
30 * The Z39.50 and record bucket interfaces now open relevant
31 catalog records in new tabs.
32 * Fixes a bug that prevented batch importing authority records.
33 * The template dropdown in the holdings editor now provides more
34 space to accommodate longer template names.
35 * The drop-down of copy tag types in the Manage Copy Tags dialog
36 now includes the owning library of the copy tag type.
41 * Fixes an issue with recalling checked-out materials.
42 * Added several missing columns to the patron bills grid.
43 * Corrected the display of the Bill Type column in the patron bills grid.
44 * Clarified the names of the "Billing Location" and "Grocery Billing
45 Location" columns in the patron bills grid.
46 * The Bill Full Details grid now includes a billing location column
47 for both circulation and grocery bills, as well as the owning library for
49 * The Billing History transactions grid now remembers any changes that
50 users make to the column settings.
51 * Fixes an issue with printing multiple copies of bills.
52 * Fixes an issue with saving self-registered patron accounts.
53 * Staff can now delete self-registered patron accounts.
58 * Fixes the marc_stream_importer to be compatible with Vandelay session
60 * Includes an accessibility improvement for the Acquisitions
61 Administration interfaces.
66 We would like to thank the following individuals who contributed code,
67 tests and documentation patches to the 3.2.3 point release of
90 This release contains bug fixes improving on Evergreen 3.2.1.
91 All bug fixes refer to the web staff client unless otherwise specified.
99 * Fixes a bug that blocked logging in from mobile browsers
100 * Fixes a readability issue with mobile menus
101 * Fixes performance issue related to grid tooltips.
102 * Fixes an issue that caused some grid columns to appear
108 * Improves the functionality of setting a default tab of a bib record
109 * The web client now remembers the most recently selected copy template
110 * Adds help tips to Print Item Labels Settings tab
111 * If you add or edit copies and/or volumes from the Holdings View tab,
112 the view now automatically refreshes to show your changes.
113 * Provides an upgrade to MODS 3.3 for older Evergreen installations.
114 * Improves usability of Z39.50 MARC View.
120 * Fixes a daylight savings time-related circulation bug.
121 * Fixes a bug that caused deleted items to show up on the holds shelf.
122 * Staff can now place multiple email addresses into the patron registration/
123 edit form, depending on the value of the `ui.patron.edit.au.email.regex`
125 * Fixes an issue with the offline circulation module.
126 * When merging two users, the non-lead account is now completely purged from
127 the database, rather than simply being marked as deleted.
128 * Fixes a bug which prevented the canceling of holds from the title
134 * Removes incorrect copy counts from metarecord search results pages
135 * Electronic resources now display in the browse interfaces
136 * Restores ability to request password resets
138 System administration
139 ^^^^^^^^^^^^^^^^^^^^^
141 * The example Apache 2.4 configuration now enables remoteip.
142 * Improves syntax in the fm_idl file.
147 We would like to thank the following individuals who contributed code,
148 tests and documentation patches to the 3.2.2 point release of
172 This release contains bug fixes improving on Evergreen 3.2.0.
177 * Adds several columns to the items out grid.
178 * Adds the ability to copy patron addresses to the clipboard.
179 * Fixes several issues with adding new items and call numbers.
180 * Adds links to catalog records from the query and pending tabs of the Record Buckets interface.
181 * Corrects the date format used in several bucket interfaces.
182 * Adds a loading spinner to interfaces that are embedded in the web staff client via iframe
183 (such as the catalog).
184 * The new Angular 6 interfaces now use the correct favicon.
188 We would like to thank the following individuals who contributed code,
189 tests and documentation patches to the 3.2.1 point release of
210 Disabling of Legacy XUL Staff Client
211 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
212 The legacy XUL staff client is no longer supported in Evergreen
213 3.2.x and the server-side installation no longer supports a
214 direct connection by a version XUL client by default. *All
215 users of Evergreen 3.2.x are strongly urged to complete their
216 switch to the web staff client as part of upgrading to 3.2.x.*
218 Evergreen administrators who for some reason continue to wish
219 to deploy the XUL staff client can do so at their risk by
220 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
221 and using `make_release` to create installers for the staff client.
222 However, no community support will be provided for the XUL client.
229 Existing Acquisitions report templates that reference the invoice 'complete'
230 field should be modified to check whether the new close_date field is NOT NULL
233 At deploy time, all invoices with a 'complete' value of TRUE will have their
234 'close_date' field set to NOW. A value is required, since this field is
235 now the source of whether an invoice is open or closed.
237 However, no values will be applied to the closed_by field for already closed
241 Angular6 Base Application
242 ~~~~~~~~~~~~~~~~~~~~~~~~~
244 System Admin Upgrade Notes
245 ^^^^^^^^^^^^^^^^^^^^^^^^^^
247 Like the AngularJS application, Evergreen releases will come with all
248 web browser staff client code pre-compiled. Admins only need to add an
249 Apache configuration change.
251 Add the following stanza to /etc/apache2/eg_vhost.conf.
254 --------------------------------------------------------------------------
255 RewriteCond %{REQUEST_URI} ^/eg2/
256 RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
257 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
259 <Directory "/openils/var/web/eg2/en-US">
260 FallbackResource /eg2/en-US/index.html
262 --------------------------------------------------------------------------
264 For multi-locale sites, see the bottom section of
265 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
266 configuration. The section starts with "/eg2/ client setup and locale
269 Developer Upgrade Notes
270 ^^^^^^^^^^^^^^^^^^^^^^^
272 Developers building Angular code on existing installations need to update
273 their version of NodeJS by re-running the -developer prereqs installer.
276 --------------------------------------------------------------------------
277 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
278 --------------------------------------------------------------------------
281 Asynchronous Vandelay Imports
282 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
284 Users of NGINX as a reverse proxy may need to set a suitable
285 `client_max_body_size` value in the NGINX configuration so that large
286 MARC record uploads are not truncated. Note that this would have
287 always been necessary, but since this feature allows larger files
288 to be more reliably queued and imported, the need to set `client_max_body_size`
289 became more apparent.
292 Browser Client Settings & Preferences Stored on the Server
293 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
295 A new permission APPLY_WORKSTATION_SETTING has been added to control who
296 may apply values to workstation settings. Use something like the following
297 to apply the permission to all staff accounts (mileage may vary):
300 --------------------------------------------------------------------------
301 INSERT INTO permission.grp_perm_map (grp, perm, depth)
303 (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
304 (SELECT id FROM permission.perm_list WHERE code =
305 'APPLY_WORKSTATION_SETTING'),
308 --------------------------------------------------------------------------
310 Workstation setting types matching values previously stored in the browser
311 (via localStorage or Hatch) are created as part of this feature. During
312 upgrade, admins should consider whether any of these new setting types
313 should be transferred to user and/or org unit settings instead. Setting
314 type changes can be made at any time, but when a setting type is deleted
315 all of its data is deleted, so a change in type means re-applying the
316 settings in the browser client.
318 Values stored in the browser will automatically migrate to server settings
319 as each setting is accessed in the browser client. Once migrated, the
320 in-browser copies are deleted.
322 If a setting type does not exist where the browser expects one, the
323 value is stored in-browser instead and a warning is issued in the console.
335 Auto-Cancel Line items When All Copies Are Canceled
336 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
337 When a copy (line item detail) is canceled through the Acquisitions interface,
338 the parent line item is also canceled if all copies for that line item are also
339 canceled. The cancel reason given will come from:
341 . The cancel reason for the just-canceled copy if it's a Keep Debits true
343 . The cancel reason from any other copy on the lineitem that has a Keep
344 Debits true cancel reason.
345 . The cancel reason for the just-canceled copy if no copies have a Keep
346 Debits true cancel reason.
349 Invoice Closed Date and Closed By Fields
350 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
351 Acquisitions invoices have 2 new fields:
353 * Close Date -- This is set to the time when the ACQ user clicks the "Close"
354 button in the invoice interface.
355 ** This field 'replaces' the existing 'complete' field. An invoice is
356 considered complete if a close date value is set.
357 * Closed By -- This is set to the logged in staff user who performs the
360 As with the now-defunct 'complete' field, but new fields are cleared in the
361 event an invoice is reopened.
363 These new fields are visible in the invoice interface under the
364 'Show Details' action for closed invoices.
366 Upgrading Invoice Reports
367 +++++++++++++++++++++++++
369 Existing report templates that reference the invoice 'complete' field
370 should be modified to check whether the new close_date field is NOT NULL
373 Other Upgrade Considerations
374 ++++++++++++++++++++++++++++
376 At deploy time, all invoices with a 'complete' value of TRUE will have their
377 'close_date' field set to NOW. A value is required, since this field is
378 now the source of whether an invoice is open or closed.
380 However, no values will be applied to the closed_by field for already closed
385 Patron Acquisitions Requests
386 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
388 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.
395 Hold Targeter Script has been Replaced
396 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
398 The original hold_targeter.pl script has been renamed to
399 "hold_targeter_legacy.pl", and the new-style hold targeting
400 script has been renamed to "hold_targeter.pl". Administrators
401 will want to change their crontab files to reflect this.
405 ---------------------------------------------------------------------
406 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl $SRF_CORE
407 ---------------------------------------------------------------------
411 -----------------------------------------------------------------------------------
412 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl --osrf-config
414 -----------------------------------------------------------------------------------
416 The sample crontab file at `Open-ILS/examples/crontab.example` reflects
424 Angular6 Base Application
425 ^^^^^^^^^^^^^^^^^^^^^^^^^
426 With Evergreen 3.2, we introduce the initial infrastructure for
427 migrating to a new version of Angular. The structure of the new code
428 is quite different from the AngularJS code and it runs as a separate
429 application which communicates with the AngularJS app via shared storage
430 and in-page URLs that link back and forth between the two.
432 For this release, users will only be directed to the new Angular site
433 when navigating to Administration => Acquisitions Administration. Once
434 on this page, some of the admin interfaces will presented as Angular6
435 interfaces, while others will direct users back to the AngularJS
436 application. The Angular6 interfaces are the simpler, grid-based
439 Acquisitions Admin Angular6 Interfaces
440 ++++++++++++++++++++++++++++++++++++++
445 * Claim Policy Actions
453 * Invoice Payment Method
455 * Line Item MARC Attribute Definitions
457 System Admin Upgrade Notes
458 ++++++++++++++++++++++++++
460 Like the AngularJS application, Evergreen releases will come with all
461 web browser staff client code pre-compiled. Admins only need to add an
462 Apache configuration change.
464 Add the following stanza to /etc/apache2/eg_vhost.conf.
467 --------------------------------------------------------------------------
468 RewriteCond %{REQUEST_URI} ^/eg2/
469 RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
470 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
472 <Directory "/openils/var/web/eg2/en-US">
473 FallbackResource /eg2/en-US/index.html
475 --------------------------------------------------------------------------
477 For multi-locale sites, see the bottom section of
478 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
479 configuration. The section starts with "/eg2/ client setup and locale
482 Developer Upgrade Notes
483 +++++++++++++++++++++++
485 Developers building Angular code on existing installations need to update
486 their version of NodeJS by re-running the -developer prereqs installer.
489 --------------------------------------------------------------------------
490 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
491 --------------------------------------------------------------------------
497 Add UPC to z39.50 search for OCLC and LOC
498 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
499 Add UPC as a search attribute for both OCLC and LOC targets in
500 z39.50 for cataloging.
503 Asynchronous Vandelay Imports
504 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
506 Vandelay imports are now monitored from the browser client asynchronously,
507 meaning the client requests updates from the server instead of waiting for
508 the server to respond to the original import request. This changes allows
509 for incremental progress updates in the browser client.
514 This adds a new database table vandelay.session_tracker for tracking
515 in-progress vandelay upload activity. A new tracker row is added for
516 each of "upload", "enqueue", and "import" actions, linked for a given
517 session by the value stored in the "session_key" field.
519 The table tracks other potentially useful data, like the staff member
520 and workstation where the action was performed.
524 Users of NGINX as a reverse proxy may need to set a suitable
525 `client_max_body_size` value in the NGINX configuration so that large
526 MARC record uploads are not truncated. Note that this would have
527 always been necessary, but since this feature allows larger files
528 to be more reliably queued and imported, the need to set `client_max_body_size`
529 became more apparent.
534 Support for Last Inventory Date
535 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
536 Evergreen now provides an option to add an inventory date to items to facilitate
537 the process of performing inventory in libraries. Staff can add an inventory
538 date to an item in one of the following ways:
539 * From the check in screen, there is now an Update Inventory check in modifier.
540 When selected, scanned barcodes will have the current date/time added as the
541 inventory date while the item is checked in.
542 * From the Item Status screen, an action is available to add the current
543 date/time as the inventory date to selected items.
545 This new feature will also store the workstation that was used when the
546 inventory date was updated.
550 Parallel Ingest with pingest.pl
551 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
552 A program named pingest.pl is now installed to allow faster bibliographic record
553 ingest. It performs ingest in parallel so that multiple batches can
554 be done simultaneously. It operates by splitting the records to be
555 ingested up into batches and running all of the ingest methods on each
556 batch. You may pass in options to control how many batches are run at
557 the same time, how many records there are per batch, and which ingest
560 NOTE: The browse ingest is presently done in a single process over all
561 of the input records as it cannot run in parallel with itself. It
562 does, however, run in parallel with the other ingests.
566 pingest.pl accepts the following command line options:
569 The server where PostgreSQL runs (either host name or IP address).
570 The default is read from the PGHOST environment variable or
574 The port that PostgreSQL listens to on host. The default is read
575 from the PGPORT environment variable or 5432.
578 The database to connect to on the host. The default is read from
579 the PGDATABASE environment variable or "evergreen."
582 The username for database connections. The default is read from
583 the PGUSER environment variable or "evergreen."
586 The password for database connections. The default is read from
587 the PGPASSWORD environment variable or "evergreen."
590 Number of records to process per batch. The default is 10,000.
593 Max number of worker processes (i.e. the number of batches to
594 process simultaneously). The default is 8.
601 Skip the selected reingest component.
604 Start processing at this record ID.
607 Stop processing when this record ID is reached.
610 Read record IDs to reingest from standard input. This option
611 conflicts with --start-id and/or --end-id.
614 Stop processing after this many total seconds have passed. The
615 default is to run until all records have been processed.
622 View Authority Record by Database ID
623 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
625 A new interface allows catalogers to retrieve a specific
626 authority record using its database ID. Catalogers can
627 find those IDs in subfield $0 of matching fields in
628 bibliographic records.
630 To use the new authority record viewer:
632 . Click *Cataloging -> Retrieve Authority Record by ID*.
633 . Type in the ID number of the authority record you are
634 interested in. Don't include any prefixes, just the ID
637 . View or edit the authority record as needed.
648 Circulation policies in Evergreen can now be configured to automatically renew
649 certain items checked out on patron accounts. Circulations will be renewed
650 automatically up to a custom limit (the `max_auto_renewal` field) and patrons
651 will not need to log in to their OPAC accounts or ask library staff to manually
654 Two new action triggers have been added to Evergreen that permit the Auto-Renew
655 feature. They can be found, configured, and enabled in Administration>Local
656 Administration>Notifications/Action Triggers. They are named **Autorenew** and
659 The **Autorenew** A/T definition uses the `checkout.due` hook to automatically
660 validate and renew (in the reactor) circulations on the day they are due,
661 grouped by user. The output events of this definition is is the input used by
662 the related **AutorenewNotify** A/T that simply uses a new hook called
663 `autorenewal` to notify patrons via email of their currently due or
666 In the webstaff's Patron Items Out page, the new column `AutoRenewalsRemaining`
667 indicates how many autorenewals are available for a particular circulation.
673 Emergency Closing Handler
674 ^^^^^^^^^^^^^^^^^^^^^^^^
676 Staff are provided with interfaces and mechanisms to create library closings
677 that, in addition to affecting future circulation and booking due dates, and
678 hold shelf expirations, will automatically move existing circulation and booking
679 due dates and hold shelf expiration times. This new functionality is
680 conceptually described as Emergency Closings and business logic implementing it
681 as the Emergency Closing Handler. It contains additions and adjustments to the
682 user interface, business logic, and database layers. Access to this
683 functionality is available through the Closed Dates Editor interface in the
684 staff client which has been ported to AngularJS.
689 This development has created new business logic code to inspect, in real time,
690 existing circulation, booking, and hold records, and modify such date and time
691 stamps so that the circulation, booking, or hold will end in the same state it
692 would have if the closing had existed at the time the circulation or booking
693 occurred, or the hold was placed and captured. Of specific note, hourly loans
694 will have their due date adjusted to be the end of the day following the
697 When the Emergency Closing is saved, any fines accrued during the closing may be
698 voided, as settings dictate, with the exception of circulations that have been
699 marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE
700 circulations with due dates that fall within the Emergency Closing, no fine
701 adjustment will be applied. Emergency Closing processing is permanent, and
702 cannot be rolled back.
704 This functionality is explicitly initiated by staff action. If staff do not
705 request an Emergency Closing, existing circulations, bookings, and holds will
706 not be processed and adjusted. However, if staff request any Closing that starts
707 nearer in time than the length of the longest circulation duration configured
708 for use in the Evergreen instance they will be prompted with the option to
709 create the closing as an Emergency Closing.
711 Action/Trigger hooks have been created for circulations and bookings that are
712 adjusted by the Emergency Closing Handler. These will facilitate the creation of
713 notifications to patrons that the due date has changed and to alert them to
714 potential changes in accrued fines.
716 Booking start dates are explicitly ignored in this implementation. Because an
717 Emergency Closing is, by its nature, an unexpected event, it will be up to staff
718 to address any bookings which intersect with a new Emergency Closings. Reports
719 can be used to identify booking start dates that overlap with a closing and that
720 may require staff intervention.
722 Staff requesting and Emergency Closing must have the new EMERGENCY_CLOSING
723 permission. Some text describing the feature.
729 Patron Preferred Name and Name Search Keywords
730 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
735 Adds a new set of patron preferred name fields for prefix, first,
736 middle, last, and suffix allowing patrons to provide preferred name
737 information. Preferred names are optional and each acts as an overlay
738 to the analogous primary name field, making it possible to provide
739 preferred name values for individual fields.
741 For example, a patron named William Erickson may have a preferred first
742 name (pref_first_given_name) of Bill, in which case the preferred name
743 would be Bill Erickson. Note a preferred last name is not required in
744 this case as the code uses primary name values as defaults when not
745 replaced with a preferred version.
747 * Patrons will see primary names displayed in the catalog when set.
748 * Staff will see both primary name and preferred name in the patron
750 * Patron searches for any given name field will search both the primary
751 and preferred name data.
752 * Preferred name fields are available in Action/Trigger templates and
753 are present in various patron-focused print templates.
758 Adds a new field to store miscellaneous patron name search terms. These
759 values are only for searching and do not appear in any interfaces, apart
760 from the patron summary side bar and the patron edit UI.
762 Included is a new search field in the patron search UI which searches
763 keyword values and all other name fields. It's essentially a global patron
772 Disabling of legacy XUL staff client
773 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
774 The legacy XUL staff client is no longer supported in Evergreen
775 3.2.x and the server-side installation no longer supports a
776 direct connection by a version XUL client by default. All
777 users of Evergreen 3.2.x are strongly urged to complete their
778 switch to the web staff client as part of upgrading to 3.2.x.
780 Evergreen administrators who for some reason continue to wish
781 to deploy the XUL staff client can do so at their risk by
782 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
783 and using `make_release` to create installers for the staff client.
784 However, no community support will be provided for the XUL client.
789 Permission Group Display Entries
790 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
791 In some cases, it is useful to have the ability to reorder permission, or to make
792 only specific groups available in the permission group selector for specific
793 Org Units. An interface has been made available to allow this.
795 Group Tree Display Entry Interface
796 ++++++++++++++++++++++++++++++++++
798 Permission Group Display Entries can be reordered, added, or removed via
799 _Administration -> Local Admin -> Permission Tree Display Entries_.
800 Select the Org Unit you wish to edit the entries in.
802 Entries may be added using the Add functionality, creating entries based
803 on permission groups that have not been added to the tree for the Org
804 Unit you wish to add them to.
806 image::media/pgtde_01.png[Group Tree Display Entry Admin UI]
810 Moving an entry will shift its position up or down in the patron profile
811 selector for a given Org Unit.
814 * Press either the *Move Up* or *Move Down* button. The entry will be
815 moved up or down, accordingly.
816 * Click *Save* to save your edits.
818 NOTE: You may only move up or down entries that have sibling entries.
822 If you want a particular Org Unit to not have access to specific
823 entries, you may remove an entry. Removing an entry will remove it from
824 view. The entry will be removed from the database.
826 * Select an entry and press the *Remove* button.
830 You may add entries from permission groups that are not currently
831 reflected in the permission group tree. This is useful for moving
832 entries to different parents, or making them root entries.
834 image::media/pgtde_02.png[Add Entry modal]
836 * If desired, select an entry to be used as the parent entry.
837 * Press the *Add* button.
838 * Select a permission group from the dropdown.
839 * If you've selected a parent entry, you may check the *Add Root Entry*
840 box to override that parent and add the entry on the root level.
841 * If you did not select a parent entry, the entry will be added on the root
846 Browser Client Settings & Preferences Stored on the Server
847 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
848 Browser client settings and preferences that should persist over time are
849 now stored as settings on the server. This allows settings to follow
850 users and workstations and reduces problems associated with losing settings
851 as a result of clearing browser data.
853 The browser client honors setting values stored as user settings, workstation
854 settings, and org unit settings, depending on which setting types are
860 * No setting can be both a user and workstation setting. They are mutually
862 * Any setting can be an org unit setting in addition to being a user or
868 Read-only settings are useful for defining values that staff can use but
869 not modify. For example, admins may wish to prevent users from locally
870 modifying the grid configuration for a given interface so it remains
871 consistent for all users.
873 A setting is read-only when an org unit setting type exists (regardless of
874 whether a value is applied) and no user or workstation setting type exists.
876 Server-Stored Workstation Settings Workstation Admin View
877 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
879 There's a new "Server Workstation Prefs" tab to the stored preferences
880 workstation admin interface. From here, users can view which
881 preferences are stored as server-stored workstation preferences and
882 delete select values.
887 A new permission APPLY_WORKSTATION_SETTING has been added to control who
888 may apply values to workstation settings. Use something like the following
889 to apply the permission to all staff accounts (mileage may vary):
892 --------------------------------------------------------------------------
893 INSERT INTO permission.grp_perm_map (grp, perm, depth)
895 (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
896 (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
899 --------------------------------------------------------------------------
901 Workstation setting types matching values previously stored in the browser
902 (via localStorage or Hatch) are created as part of this feature. During
903 upgrade, admins should consider whether any of these new setting types
904 should be transferred to user and/or org unit settings instead. Setting
905 type changes can be made at any time, but when a setting type is deleted
906 all of its data is deleted, so a change in type means re-applying the
907 settings in the browser client.
909 Values stored in the browser will automatically migrate to server settings
910 as each setting is accessed in the browser client. Once migrated, the
911 in-browser copies are deleted.
913 If a setting type does not exist where the browser expects one, the
914 value is stored in-browser instead and a warning is issued in the console.
917 More consistent terminology in the client
918 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
919 Terminology has been updated in the staff client so that we consistently use
920 the same name to describe the same thing. The following updates have been made:
922 * The term 'item' is now consistently used to describe the barcoded entity
923 that had been previously been called both an 'item' and a 'copy'. As a result,
924 we now use the terms 'item buckets', 'item tags', and 'item alerts'.
925 * The term 'volume' is no longer used in the client, with the exception of
926 serials, where the term is used to describe serial volumes. The term 'call
927 number' will replace volume in most other places.
928 * 'Holdings' is a more general term used to describe a combination of items
930 * The term 'Shelving Location' is used consistently in favor of 'Copy
941 Batch Actions In the Public Catalog
942 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
943 The public catalog now displays checkboxes on the bibliographic and
944 metarecord constituents results pages. Selecting one or more titles
945 by using the checkboxes will dynamically add those title to the
946 temporary list, which is now renamed the cart.
948 Above the results lists there is now a bar with a select-all checkbox,
949 a link to the cart management page that also indicates the number of
950 of titles in the cart, and a link to remove from the cart titles that
951 are selected on the currently displayed results page.
953 The search bar now includes an icon of a cart and displays the number
954 of titles currently in the cart. Next to that icon is a menu of cart
957 The cart actions available are Place Hold, Print Title Details,
958 Email Title Details, Add Cart to Saved List, and Clear Cart. In the
959 web staff client, the cart actions also include Add Cart to Bucket.
960 When an action is selected from this menu, the user is given an
961 opportunity to confirm the action and to optionally empty the cart
962 when the action is complete. The action is applied to all titles
965 Clicking on the cart icon brings the user to a page listing the
966 titles in the cart. From there, the user can select specific records
967 to request, print, email, add to a list, or remove from the cart.
969 The list of actions on the record details page now provides separate
970 links for adding the title to a cart or to a permanent list.
972 The permanent list management page in the public catalog now also
973 includes batch print and email actions.
975 Additional information
976 ++++++++++++++++++++++
977 * The checkboxes do not display on the metarecord results page, as
978 metarecords currently cannot be put into carts or lists.
979 * The checkboxes are displayed only if JavaScript is enabled. However,
980 users can still add items to the cart and perform batch actions on
981 the cart and on lists.
982 * A template `config.tt2` setting, `ctx.max_cart_size`, can be used to
983 set a soft limit on the number of titles that can be added to the
984 cart. If this limit is reached, checkboxes to add more records to the
985 cart are disabled unless existing titles in the cart are removed
986 first. The default value for this setting is 500.
991 This patch adds to the public catalog two routes that return JSON
994 * `GET /eg/opac/api/mylist/add?record=45`
995 * `GET /eg/opac/api/mylist/delete?record=45`
997 The JSON response is a hash containing a mylist key pointing to the list
998 of bib IDs of contents of the cart.
1000 The record parameter can be repeated to allow adding or removing
1001 records as an atomic operation. Note that this change also now available
1002 to `/eg/opac/mylist/{add,delete}`
1004 More generally, this adds a way for EGWeb context loaders to specify that
1005 a response should be emitted as JSON rather than rendering an HTML
1006 page using `Template::Toolkit`.
1008 Specifically, if the context as munged by the context loader contains
1009 a `json_response` key, the contents of that key will to provide a
1010 JSON response. The `json_response_cookie` key, if present, can be used
1011 to set a cookie as part of the response.
1013 Template Toolkit processing is bypassed entirely when emitting a JSON
1014 response, so the context loader would be entirely responsible for
1015 localization of strings in the response meant for direct human
1021 New class for searchbar when on the homepage
1022 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1024 This adds the `.searchbar-home` class to the div that contains the searchbar
1025 when on the homepage. This allows sites to customize the searchbar differently
1026 on the homepage than in other places the search bar appears (for example,
1027 offering a large, Google-style search bar on the homepage only).
1032 To make customization easier, the username hint on the OPAC login page ("Please
1033 include leading zeros...") has been moved to a separate TT2 template. If you
1034 have customized the hint text, you will need to add your modifications to
1041 The Evergreen project would like to acknowledge the following
1042 organizations that commissioned developments in this release of
1045 * BC Libraries Cooperative
1046 * Consortium Of Ohio Libraries
1048 * Georgia Public Library Service
1049 * Indiana State Library
1050 * Lake Agassiz Regrional Library
1052 * North Texas Library Consortium
1053 * Northwest Regional Library
1054 * Pennsylvania Integrated Library System
1055 * South Carolina State Library
1057 We would also like to thank the following individuals who contributed
1058 code, translations, documentations patches and tests to this release of
1063 * Andrea Buntz Neiman
1072 * Blake Graham-Henderson
1073 * Francisco J Guel-Mendoza
1091 We also thank the following organizations whose employees contributed
1094 * BC Libraries Cooperative
1097 * Equinox Open Library Initiative
1098 * Government of Manitoba
1099 * Kenton County Public Library
1100 * King County Library System
1101 * Linn-Benton Community College
1105 We regret any omissions. If a contributor has been inadvertently
1106 missed, please open a bug at http://bugs.launchpad.net/evergreen/
projects / working / Evergreen.git / blob