1 Evergreen 3.2 Release Notes
2 ===========================
8 This release contains bug fixes improving on Evergreen 3.2.1.
9 All bug fixes refer to the web staff client unless otherwise specified.
17 * Fixes a bug that blocked logging in from mobile browsers
18 * Fixes a readability issue with mobile menus
19 * Fixes performance issue related to grid tooltips.
20 * Fixes an issue that caused some grid columns to appear
26 * Improves the functionality of setting a default tab of a bib record
27 * The web client now remembers the most recently selected copy template
28 * Adds help tips to Print Item Labels Settings tab
29 * If you add or edit copies and/or volumes from the Holdings View tab,
30 the view now automatically refreshes to show your changes.
31 * Provides an upgrade to MODS 3.3 for older Evergreen installations.
32 * Improves usability of Z39.50 MARC View.
38 * Fixes a daylight savings time-related circulation bug.
39 * Fixes a bug that caused deleted items to show up on the holds shelf.
40 * Staff can now place multiple email addresses into the patron registration/
41 edit form, depending on the value of the `ui.patron.edit.au.email.regex`
43 * Fixes an issue with the offline circulation module.
44 * When merging two users, the non-lead account is now completely purged from
45 the database, rather than simply being marked as deleted.
46 * Fixes a bug which prevented the canceling of holds from the title
52 * Removes incorrect copy counts from metarecord search results pages
53 * Electronic resources now display in the browse interfaces
54 * Restores ability to request password resets
59 * The example Apache 2.4 configuration now enables remoteip.
60 * Improves syntax in the fm_idl file.
65 We would like to thank the following individuals who contributed code,
66 tests and documentation patches to the 3.2.2 point release of
90 This release contains bug fixes improving on Evergreen 3.2.0.
95 * Adds several columns to the items out grid.
96 * Adds the ability to copy patron addresses to the clipboard.
97 * Fixes several issues with adding new items and call numbers.
98 * Adds links to catalog records from the query and pending tabs of the Record Buckets interface.
99 * Corrects the date format used in several bucket interfaces.
100 * Adds a loading spinner to interfaces that are embedded in the web staff client via iframe
101 (such as the catalog).
102 * The new Angular 6 interfaces now use the correct favicon.
106 We would like to thank the following individuals who contributed code,
107 tests and documentation patches to the 3.2.1 point release of
128 Disabling of Legacy XUL Staff Client
129 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
130 The legacy XUL staff client is no longer supported in Evergreen
131 3.2.x and the server-side installation no longer supports a
132 direct connection by a version XUL client by default. *All
133 users of Evergreen 3.2.x are strongly urged to complete their
134 switch to the web staff client as part of upgrading to 3.2.x.*
136 Evergreen administrators who for some reason continue to wish
137 to deploy the XUL staff client can do so at their risk by
138 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
139 and using `make_release` to create installers for the staff client.
140 However, no community support will be provided for the XUL client.
147 Existing Acquisitions report templates that reference the invoice 'complete'
148 field should be modified to check whether the new close_date field is NOT NULL
151 At deploy time, all invoices with a 'complete' value of TRUE will have their
152 'close_date' field set to NOW. A value is required, since this field is
153 now the source of whether an invoice is open or closed.
155 However, no values will be applied to the closed_by field for already closed
159 Angular6 Base Application
160 ~~~~~~~~~~~~~~~~~~~~~~~~~
162 System Admin Upgrade Notes
163 ^^^^^^^^^^^^^^^^^^^^^^^^^^
165 Like the AngularJS application, Evergreen releases will come with all
166 web browser staff client code pre-compiled. Admins only need to add an
167 Apache configuration change.
169 Add the following stanza to /etc/apache2/eg_vhost.conf.
172 --------------------------------------------------------------------------
173 RewriteCond %{REQUEST_URI} ^/eg2/
174 RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
175 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
177 <Directory "/openils/var/web/eg2/en-US">
178 FallbackResource /eg2/en-US/index.html
180 --------------------------------------------------------------------------
182 For multi-locale sites, see the bottom section of
183 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
184 configuration. The section starts with "/eg2/ client setup and locale
187 Developer Upgrade Notes
188 ^^^^^^^^^^^^^^^^^^^^^^^
190 Developers building Angular code on existing installations need to update
191 their version of NodeJS by re-running the -developer prereqs installer.
194 --------------------------------------------------------------------------
195 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
196 --------------------------------------------------------------------------
199 Asynchronous Vandelay Imports
200 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
202 Users of NGINX as a reverse proxy may need to set a suitable
203 `client_max_body_size` value in the NGINX configuration so that large
204 MARC record uploads are not truncated. Note that this would have
205 always been necessary, but since this feature allows larger files
206 to be more reliably queued and imported, the need to set `client_max_body_size`
207 became more apparent.
210 Browser Client Settings & Preferences Stored on the Server
211 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
213 A new permission APPLY_WORKSTATION_SETTING has been added to control who
214 may apply values to workstation settings. Use something like the following
215 to apply the permission to all staff accounts (mileage may vary):
218 --------------------------------------------------------------------------
219 INSERT INTO permission.grp_perm_map (grp, perm, depth)
221 (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
222 (SELECT id FROM permission.perm_list WHERE code =
223 'APPLY_WORKSTATION_SETTING'),
226 --------------------------------------------------------------------------
228 Workstation setting types matching values previously stored in the browser
229 (via localStorage or Hatch) are created as part of this feature. During
230 upgrade, admins should consider whether any of these new setting types
231 should be transferred to user and/or org unit settings instead. Setting
232 type changes can be made at any time, but when a setting type is deleted
233 all of its data is deleted, so a change in type means re-applying the
234 settings in the browser client.
236 Values stored in the browser will automatically migrate to server settings
237 as each setting is accessed in the browser client. Once migrated, the
238 in-browser copies are deleted.
240 If a setting type does not exist where the browser expects one, the
241 value is stored in-browser instead and a warning is issued in the console.
253 Auto-Cancel Line items When All Copies Are Canceled
254 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
255 When a copy (line item detail) is canceled through the Acquisitions interface,
256 the parent line item is also canceled if all copies for that line item are also
257 canceled. The cancel reason given will come from:
259 . The cancel reason for the just-canceled copy if it's a Keep Debits true
261 . The cancel reason from any other copy on the lineitem that has a Keep
262 Debits true cancel reason.
263 . The cancel reason for the just-canceled copy if no copies have a Keep
264 Debits true cancel reason.
267 Invoice Closed Date and Closed By Fields
268 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
269 Acquisitions invoices have 2 new fields:
271 * Close Date -- This is set to the time when the ACQ user clicks the "Close"
272 button in the invoice interface.
273 ** This field 'replaces' the existing 'complete' field. An invoice is
274 considered complete if a close date value is set.
275 * Closed By -- This is set to the logged in staff user who performs the
278 As with the now-defunct 'complete' field, but new fields are cleared in the
279 event an invoice is reopened.
281 These new fields are visible in the invoice interface under the
282 'Show Details' action for closed invoices.
284 Upgrading Invoice Reports
285 +++++++++++++++++++++++++
287 Existing report templates that reference the invoice 'complete' field
288 should be modified to check whether the new close_date field is NOT NULL
291 Other Upgrade Considerations
292 ++++++++++++++++++++++++++++
294 At deploy time, all invoices with a 'complete' value of TRUE will have their
295 'close_date' field set to NOW. A value is required, since this field is
296 now the source of whether an invoice is open or closed.
298 However, no values will be applied to the closed_by field for already closed
303 Patron Acquisitions Requests
304 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
306 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.
313 Hold Targeter Script has been Replaced
314 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
316 The original hold_targeter.pl script has been renamed to
317 "hold_targeter_legacy.pl", and the new-style hold targeting
318 script has been renamed to "hold_targeter.pl". Administrators
319 will want to change their crontab files to reflect this.
323 ---------------------------------------------------------------------
324 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl $SRF_CORE
325 ---------------------------------------------------------------------
329 -----------------------------------------------------------------------------------
330 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl --osrf-config
332 -----------------------------------------------------------------------------------
334 The sample crontab file at `Open-ILS/examples/crontab.example` reflects
342 Angular6 Base Application
343 ^^^^^^^^^^^^^^^^^^^^^^^^^
344 With Evergreen 3.2, we introduce the initial infrastructure for
345 migrating to a new version of Angular. The structure of the new code
346 is quite different from the AngularJS code and it runs as a separate
347 application which communicates with the AngularJS app via shared storage
348 and in-page URLs that link back and forth between the two.
350 For this release, users will only be directed to the new Angular site
351 when navigating to Administration => Acquisitions Administration. Once
352 on this page, some of the admin interfaces will presented as Angular6
353 interfaces, while others will direct users back to the AngularJS
354 application. The Angular6 interfaces are the simpler, grid-based
357 Acquisitions Admin Angular6 Interfaces
358 ++++++++++++++++++++++++++++++++++++++
363 * Claim Policy Actions
371 * Invoice Payment Method
373 * Line Item MARC Attribute Definitions
375 System Admin Upgrade Notes
376 ++++++++++++++++++++++++++
378 Like the AngularJS application, Evergreen releases will come with all
379 web browser staff client code pre-compiled. Admins only need to add an
380 Apache configuration change.
382 Add the following stanza to /etc/apache2/eg_vhost.conf.
385 --------------------------------------------------------------------------
386 RewriteCond %{REQUEST_URI} ^/eg2/
387 RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
388 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
390 <Directory "/openils/var/web/eg2/en-US">
391 FallbackResource /eg2/en-US/index.html
393 --------------------------------------------------------------------------
395 For multi-locale sites, see the bottom section of
396 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
397 configuration. The section starts with "/eg2/ client setup and locale
400 Developer Upgrade Notes
401 +++++++++++++++++++++++
403 Developers building Angular code on existing installations need to update
404 their version of NodeJS by re-running the -developer prereqs installer.
407 --------------------------------------------------------------------------
408 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
409 --------------------------------------------------------------------------
415 Add UPC to z39.50 search for OCLC and LOC
416 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
417 Add UPC as a search attribute for both OCLC and LOC targets in
418 z39.50 for cataloging.
421 Asynchronous Vandelay Imports
422 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
424 Vandelay imports are now monitored from the browser client asynchronously,
425 meaning the client requests updates from the server instead of waiting for
426 the server to respond to the original import request. This changes allows
427 for incremental progress updates in the browser client.
432 This adds a new database table vandelay.session_tracker for tracking
433 in-progress vandelay upload activity. A new tracker row is added for
434 each of "upload", "enqueue", and "import" actions, linked for a given
435 session by the value stored in the "session_key" field.
437 The table tracks other potentially useful data, like the staff member
438 and workstation where the action was performed.
442 Users of NGINX as a reverse proxy may need to set a suitable
443 `client_max_body_size` value in the NGINX configuration so that large
444 MARC record uploads are not truncated. Note that this would have
445 always been necessary, but since this feature allows larger files
446 to be more reliably queued and imported, the need to set `client_max_body_size`
447 became more apparent.
452 Support for Last Inventory Date
453 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
454 Evergreen now provides an option to add an inventory date to items to facilitate
455 the process of performing inventory in libraries. Staff can add an inventory
456 date to an item in one of the following ways:
457 * From the check in screen, there is now an Update Inventory check in modifier.
458 When selected, scanned barcodes will have the current date/time added as the
459 inventory date while the item is checked in.
460 * From the Item Status screen, an action is available to add the current
461 date/time as the inventory date to selected items.
463 This new feature will also store the workstation that was used when the
464 inventory date was updated.
468 Parallel Ingest with pingest.pl
469 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
470 A program named pingest.pl is now installed to allow faster bibliographic record
471 ingest. It performs ingest in parallel so that multiple batches can
472 be done simultaneously. It operates by splitting the records to be
473 ingested up into batches and running all of the ingest methods on each
474 batch. You may pass in options to control how many batches are run at
475 the same time, how many records there are per batch, and which ingest
478 NOTE: The browse ingest is presently done in a single process over all
479 of the input records as it cannot run in parallel with itself. It
480 does, however, run in parallel with the other ingests.
484 pingest.pl accepts the following command line options:
487 The server where PostgreSQL runs (either host name or IP address).
488 The default is read from the PGHOST environment variable or
492 The port that PostgreSQL listens to on host. The default is read
493 from the PGPORT environment variable or 5432.
496 The database to connect to on the host. The default is read from
497 the PGDATABASE environment variable or "evergreen."
500 The username for database connections. The default is read from
501 the PGUSER environment variable or "evergreen."
504 The password for database connections. The default is read from
505 the PGPASSWORD environment variable or "evergreen."
508 Number of records to process per batch. The default is 10,000.
511 Max number of worker processes (i.e. the number of batches to
512 process simultaneously). The default is 8.
519 Skip the selected reingest component.
522 Start processing at this record ID.
525 Stop processing when this record ID is reached.
528 Read record IDs to reingest from standard input. This option
529 conflicts with --start-id and/or --end-id.
532 Stop processing after this many total seconds have passed. The
533 default is to run until all records have been processed.
540 View Authority Record by Database ID
541 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
543 A new interface allows catalogers to retrieve a specific
544 authority record using its database ID. Catalogers can
545 find those IDs in subfield $0 of matching fields in
546 bibliographic records.
548 To use the new authority record viewer:
550 . Click *Cataloging -> Retrieve Authority Record by ID*.
551 . Type in the ID number of the authority record you are
552 interested in. Don't include any prefixes, just the ID
555 . View or edit the authority record as needed.
566 Circulation policies in Evergreen can now be configured to automatically renew
567 certain items checked out on patron accounts. Circulations will be renewed
568 automatically up to a custom limit (the `max_auto_renewal` field) and patrons
569 will not need to log in to their OPAC accounts or ask library staff to manually
572 Two new action triggers have been added to Evergreen that permit the Auto-Renew
573 feature. They can be found, configured, and enabled in Administration>Local
574 Administration>Notifications/Action Triggers. They are named **Autorenew** and
577 The **Autorenew** A/T definition uses the `checkout.due` hook to automatically
578 validate and renew (in the reactor) circulations on the day they are due,
579 grouped by user. The output events of this definition is is the input used by
580 the related **AutorenewNotify** A/T that simply uses a new hook called
581 `autorenewal` to notify patrons via email of their currently due or
584 In the webstaff's Patron Items Out page, the new column `AutoRenewalsRemaining`
585 indicates how many autorenewals are available for a particular circulation.
591 Emergency Closing Handler
592 ^^^^^^^^^^^^^^^^^^^^^^^^
594 Staff are provided with interfaces and mechanisms to create library closings
595 that, in addition to affecting future circulation and booking due dates, and
596 hold shelf expirations, will automatically move existing circulation and booking
597 due dates and hold shelf expiration times. This new functionality is
598 conceptually described as Emergency Closings and business logic implementing it
599 as the Emergency Closing Handler. It contains additions and adjustments to the
600 user interface, business logic, and database layers. Access to this
601 functionality is available through the Closed Dates Editor interface in the
602 staff client which has been ported to AngularJS.
607 This development has created new business logic code to inspect, in real time,
608 existing circulation, booking, and hold records, and modify such date and time
609 stamps so that the circulation, booking, or hold will end in the same state it
610 would have if the closing had existed at the time the circulation or booking
611 occurred, or the hold was placed and captured. Of specific note, hourly loans
612 will have their due date adjusted to be the end of the day following the
615 When the Emergency Closing is saved, any fines accrued during the closing may be
616 voided, as settings dictate, with the exception of circulations that have been
617 marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE
618 circulations with due dates that fall within the Emergency Closing, no fine
619 adjustment will be applied. Emergency Closing processing is permanent, and
620 cannot be rolled back.
622 This functionality is explicitly initiated by staff action. If staff do not
623 request an Emergency Closing, existing circulations, bookings, and holds will
624 not be processed and adjusted. However, if staff request any Closing that starts
625 nearer in time than the length of the longest circulation duration configured
626 for use in the Evergreen instance they will be prompted with the option to
627 create the closing as an Emergency Closing.
629 Action/Trigger hooks have been created for circulations and bookings that are
630 adjusted by the Emergency Closing Handler. These will facilitate the creation of
631 notifications to patrons that the due date has changed and to alert them to
632 potential changes in accrued fines.
634 Booking start dates are explicitly ignored in this implementation. Because an
635 Emergency Closing is, by its nature, an unexpected event, it will be up to staff
636 to address any bookings which intersect with a new Emergency Closings. Reports
637 can be used to identify booking start dates that overlap with a closing and that
638 may require staff intervention.
640 Staff requesting and Emergency Closing must have the new EMERGENCY_CLOSING
641 permission. Some text describing the feature.
647 Patron Preferred Name and Name Search Keywords
648 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
653 Adds a new set of patron preferred name fields for prefix, first,
654 middle, last, and suffix allowing patrons to provide preferred name
655 information. Preferred names are optional and each acts as an overlay
656 to the analogous primary name field, making it possible to provide
657 preferred name values for individual fields.
659 For example, a patron named William Erickson may have a preferred first
660 name (pref_first_given_name) of Bill, in which case the preferred name
661 would be Bill Erickson. Note a preferred last name is not required in
662 this case as the code uses primary name values as defaults when not
663 replaced with a preferred version.
665 * Patrons will see primary names displayed in the catalog when set.
666 * Staff will see both primary name and preferred name in the patron
668 * Patron searches for any given name field will search both the primary
669 and preferred name data.
670 * Preferred name fields are available in Action/Trigger templates and
671 are present in various patron-focused print templates.
676 Adds a new field to store miscellaneous patron name search terms. These
677 values are only for searching and do not appear in any interfaces, apart
678 from the patron summary side bar and the patron edit UI.
680 Included is a new search field in the patron search UI which searches
681 keyword values and all other name fields. It's essentially a global patron
690 Disabling of legacy XUL staff client
691 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
692 The legacy XUL staff client is no longer supported in Evergreen
693 3.2.x and the server-side installation no longer supports a
694 direct connection by a version XUL client by default. All
695 users of Evergreen 3.2.x are strongly urged to complete their
696 switch to the web staff client as part of upgrading to 3.2.x.
698 Evergreen administrators who for some reason continue to wish
699 to deploy the XUL staff client can do so at their risk by
700 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
701 and using `make_release` to create installers for the staff client.
702 However, no community support will be provided for the XUL client.
707 Permission Group Display Entries
708 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
709 In some cases, it is useful to have the ability to reorder permission, or to make
710 only specific groups available in the permission group selector for specific
711 Org Units. An interface has been made available to allow this.
713 Group Tree Display Entry Interface
714 ++++++++++++++++++++++++++++++++++
716 Permission Group Display Entries can be reordered, added, or removed via
717 _Administration -> Local Admin -> Permission Tree Display Entries_.
718 Select the Org Unit you wish to edit the entries in.
720 Entries may be added using the Add functionality, creating entries based
721 on permission groups that have not been added to the tree for the Org
722 Unit you wish to add them to.
724 image::media/pgtde_01.png[Group Tree Display Entry Admin UI]
728 Moving an entry will shift its position up or down in the patron profile
729 selector for a given Org Unit.
732 * Press either the *Move Up* or *Move Down* button. The entry will be
733 moved up or down, accordingly.
734 * Click *Save* to save your edits.
736 NOTE: You may only move up or down entries that have sibling entries.
740 If you want a particular Org Unit to not have access to specific
741 entries, you may remove an entry. Removing an entry will remove it from
742 view. The entry will be removed from the database.
744 * Select an entry and press the *Remove* button.
748 You may add entries from permission groups that are not currently
749 reflected in the permission group tree. This is useful for moving
750 entries to different parents, or making them root entries.
752 image::media/pgtde_02.png[Add Entry modal]
754 * If desired, select an entry to be used as the parent entry.
755 * Press the *Add* button.
756 * Select a permission group from the dropdown.
757 * If you've selected a parent entry, you may check the *Add Root Entry*
758 box to override that parent and add the entry on the root level.
759 * If you did not select a parent entry, the entry will be added on the root
764 Browser Client Settings & Preferences Stored on the Server
765 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
766 Browser client settings and preferences that should persist over time are
767 now stored as settings on the server. This allows settings to follow
768 users and workstations and reduces problems associated with losing settings
769 as a result of clearing browser data.
771 The browser client honors setting values stored as user settings, workstation
772 settings, and org unit settings, depending on which setting types are
778 * No setting can be both a user and workstation setting. They are mutually
780 * Any setting can be an org unit setting in addition to being a user or
786 Read-only settings are useful for defining values that staff can use but
787 not modify. For example, admins may wish to prevent users from locally
788 modifying the grid configuration for a given interface so it remains
789 consistent for all users.
791 A setting is read-only when an org unit setting type exists (regardless of
792 whether a value is applied) and no user or workstation setting type exists.
794 Server-Stored Workstation Settings Workstation Admin View
795 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
797 There's a new "Server Workstation Prefs" tab to the stored preferences
798 workstation admin interface. From here, users can view which
799 preferences are stored as server-stored workstation preferences and
800 delete select values.
805 A new permission APPLY_WORKSTATION_SETTING has been added to control who
806 may apply values to workstation settings. Use something like the following
807 to apply the permission to all staff accounts (mileage may vary):
810 --------------------------------------------------------------------------
811 INSERT INTO permission.grp_perm_map (grp, perm, depth)
813 (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
814 (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
817 --------------------------------------------------------------------------
819 Workstation setting types matching values previously stored in the browser
820 (via localStorage or Hatch) are created as part of this feature. During
821 upgrade, admins should consider whether any of these new setting types
822 should be transferred to user and/or org unit settings instead. Setting
823 type changes can be made at any time, but when a setting type is deleted
824 all of its data is deleted, so a change in type means re-applying the
825 settings in the browser client.
827 Values stored in the browser will automatically migrate to server settings
828 as each setting is accessed in the browser client. Once migrated, the
829 in-browser copies are deleted.
831 If a setting type does not exist where the browser expects one, the
832 value is stored in-browser instead and a warning is issued in the console.
835 More consistent terminology in the client
836 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
837 Terminology has been updated in the staff client so that we consistently use
838 the same name to describe the same thing. The following updates have been made:
840 * The term 'item' is now consistently used to describe the barcoded entity
841 that had been previously been called both an 'item' and a 'copy'. As a result,
842 we now use the terms 'item buckets', 'item tags', and 'item alerts'.
843 * The term 'volume' is no longer used in the client, with the exception of
844 serials, where the term is used to describe serial volumes. The term 'call
845 number' will replace volume in most other places.
846 * 'Holdings' is a more general term used to describe a combination of items
848 * The term 'Shelving Location' is used consistently in favor of 'Copy
859 Batch Actions In the Public Catalog
860 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
861 The public catalog now displays checkboxes on the bibliographic and
862 metarecord constituents results pages. Selecting one or more titles
863 by using the checkboxes will dynamically add those title to the
864 temporary list, which is now renamed the cart.
866 Above the results lists there is now a bar with a select-all checkbox,
867 a link to the cart management page that also indicates the number of
868 of titles in the cart, and a link to remove from the cart titles that
869 are selected on the currently displayed results page.
871 The search bar now includes an icon of a cart and displays the number
872 of titles currently in the cart. Next to that icon is a menu of cart
875 The cart actions available are Place Hold, Print Title Details,
876 Email Title Details, Add Cart to Saved List, and Clear Cart. In the
877 web staff client, the cart actions also include Add Cart to Bucket.
878 When an action is selected from this menu, the user is given an
879 opportunity to confirm the action and to optionally empty the cart
880 when the action is complete. The action is applied to all titles
883 Clicking on the cart icon brings the user to a page listing the
884 titles in the cart. From there, the user can select specific records
885 to request, print, email, add to a list, or remove from the cart.
887 The list of actions on the record details page now provides separate
888 links for adding the title to a cart or to a permanent list.
890 The permanent list management page in the public catalog now also
891 includes batch print and email actions.
893 Additional information
894 ++++++++++++++++++++++
895 * The checkboxes do not display on the metarecord results page, as
896 metarecords currently cannot be put into carts or lists.
897 * The checkboxes are displayed only if JavaScript is enabled. However,
898 users can still add items to the cart and perform batch actions on
899 the cart and on lists.
900 * A template `config.tt2` setting, `ctx.max_cart_size`, can be used to
901 set a soft limit on the number of titles that can be added to the
902 cart. If this limit is reached, checkboxes to add more records to the
903 cart are disabled unless existing titles in the cart are removed
904 first. The default value for this setting is 500.
909 This patch adds to the public catalog two routes that return JSON
912 * `GET /eg/opac/api/mylist/add?record=45`
913 * `GET /eg/opac/api/mylist/delete?record=45`
915 The JSON response is a hash containing a mylist key pointing to the list
916 of bib IDs of contents of the cart.
918 The record parameter can be repeated to allow adding or removing
919 records as an atomic operation. Note that this change also now available
920 to `/eg/opac/mylist/{add,delete}`
922 More generally, this adds a way for EGWeb context loaders to specify that
923 a response should be emitted as JSON rather than rendering an HTML
924 page using `Template::Toolkit`.
926 Specifically, if the context as munged by the context loader contains
927 a `json_response` key, the contents of that key will to provide a
928 JSON response. The `json_response_cookie` key, if present, can be used
929 to set a cookie as part of the response.
931 Template Toolkit processing is bypassed entirely when emitting a JSON
932 response, so the context loader would be entirely responsible for
933 localization of strings in the response meant for direct human
939 New class for searchbar when on the homepage
940 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
942 This adds the `.searchbar-home` class to the div that contains the searchbar
943 when on the homepage. This allows sites to customize the searchbar differently
944 on the homepage than in other places the search bar appears (for example,
945 offering a large, Google-style search bar on the homepage only).
950 To make customization easier, the username hint on the OPAC login page ("Please
951 include leading zeros...") has been moved to a separate TT2 template. If you
952 have customized the hint text, you will need to add your modifications to
959 The Evergreen project would like to acknowledge the following
960 organizations that commissioned developments in this release of
963 * BC Libraries Cooperative
964 * Consortium Of Ohio Libraries
966 * Georgia Public Library Service
967 * Indiana State Library
968 * Lake Agassiz Regrional Library
970 * North Texas Library Consortium
971 * Northwest Regional Library
972 * Pennsylvania Integrated Library System
973 * South Carolina State Library
975 We would also like to thank the following individuals who contributed
976 code, translations, documentations patches and tests to this release of
981 * Andrea Buntz Neiman
990 * Blake Graham-Henderson
991 * Francisco J Guel-Mendoza
1009 We also thank the following organizations whose employees contributed
1012 * BC Libraries Cooperative
1015 * Equinox Open Library Initiative
1016 * Government of Manitoba
1017 * Kenton County Public Library
1018 * King County Library System
1019 * Linn-Benton Community College
1023 We regret any omissions. If a contributor has been inadvertently
1024 missed, please open a bug at http://bugs.launchpad.net/evergreen/
projects / working / Evergreen.git / blob