1 Evergreen 3.2 Release Notes
2 ===========================
18 Auto-Cancel Line items When All Copies Are Canceled
19 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
20 When a copy (line item detail) is canceled through the Acquisitions interface,
21 the parent line item is also canceled if all copies for that line item are also
22 canceled. The cancel reason given will come from:
24 . The cancel reason for the just-canceled copy if it's a Keep Debits true
26 . The cancel reason from any other copy on the lineitem that has a Keep
27 Debits true cancel reason.
28 . The cancel reason for the just-canceled copy if no copies have a Keep
29 Debits true cancel reason.
32 Invoice Closed Date and Closed By Fields
33 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
34 Acquisitions invoices have 2 new fields:
36 * Close Date -- This is set to the time when the ACQ user clicks the "Close"
37 button in the invoice interface.
38 ** This field 'replaces' the existing 'complete' field. An invoice is
39 considered complete if a close date value is set.
40 * Closed By -- This is set to the logged in staff user who performs the
43 As with the now-defunct 'complete' field, but new fields are cleared in the
44 event an invoice is reopened.
46 These new fields are visible in the invoice interface under the
47 'Show Details' action for closed invoices.
49 Upgrading Invoice Reports
50 +++++++++++++++++++++++++
52 Existing report templates that reference the invoice 'complete' field
53 should be modified to check whether the new close_date field is NOT NULL
56 Other Upgrade Considerations
57 ++++++++++++++++++++++++++++
59 At deploy time, all invoices with a 'complete' value of TRUE will have their
60 'close_date' field set to NOW. A value is required, since this field is
61 now the source of whether an invoice is open or closed.
63 However, no values will be applied to the closed_by field for already closed
68 Patron Acquisitions Requests
69 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
71 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.
78 Hold Targeter Script has been Replaced
79 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
81 The original hold_targeter.pl script has been renamed to
82 "hold_targeter_legacy.pl", and the new-style hold targeting
83 script has been renamed to "hold_targeter.pl". Administrators
84 will want to change their crontab files to reflect this.
88 ---------------------------------------------------------------------
89 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl $SRF_CORE
90 ---------------------------------------------------------------------
94 -----------------------------------------------------------------------------------
95 -*/15 * * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter.pl --osrf-config
97 -----------------------------------------------------------------------------------
99 The sample crontab file at `Open-ILS/examples/crontab.example` reflects
107 Angular6 Base Application
108 ^^^^^^^^^^^^^^^^^^^^^^^^^
109 With Evergreen 3.2, we introduce the initial infrastructure for
110 migrating to a new version of Angular. The structure of the new code
111 is quite different from the AngularJS code and it runs as a separate
112 application which communicates with the AngularJS app via shared storage
113 and in-page URLs that link back and forth between the two.
115 For this release, users will only be directed to the new Angular site
116 when navigating to Administration => Acquisitions Administration. Once
117 on this page, some of the admin interfaces will presented as Angular6
118 interfaces, while others will direct users back to the AngularJS
119 application. The Angular6 interfaces are the simpler, grid-based
122 Acquisitions Admin Angular6 Interfaces
123 ++++++++++++++++++++++++++++++++++++++
128 * Claim Policy Actions
136 * Invoice Payment Method
138 * Line Item MARC Attribute Definitions
140 System Admin Upgrade Notes
141 ++++++++++++++++++++++++++
143 Like the AngularJS application, Evergreen releases will come with all
144 web browser staff client code pre-compiled. Admins only need to add an
145 Apache configuration change.
147 Add the following stanza to /etc/apache2/eg_vhost.conf.
150 --------------------------------------------------------------------------
151 RewriteCond %{REQUEST_URI} ^/eg2/
152 RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
153 RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [R=307,L]
155 <Directory "/openils/var/web/eg2/en-US">
156 FallbackResource /eg2/en-US/index.html
158 --------------------------------------------------------------------------
160 For multi-locale sites, see the bottom section of
161 Open-ILS/examples/apache[_24]/eg_vhost.conf.in for a sample fr-CA
162 configuration. The section starts with "/eg2/ client setup and locale
165 Developer Upgrade Notes
166 +++++++++++++++++++++++
168 Developers building Angular code on existing installations need to update
169 their version of NodeJS by re-running the -developer prereqs installer.
172 --------------------------------------------------------------------------
173 sudo make -f Open-ILS/src/extras/Makefile.install <osname>-developer
174 --------------------------------------------------------------------------
180 Add UPC to z39.50 search for OCLC and LOC
181 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
182 Add UPC as a search attribute for both OCLC and LOC targets in
183 z39.50 for cataloging.
186 Asynchronous Vandelay Imports
187 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
189 Vandelay imports are now monitored from the browser client asynchronously,
190 meaning the client requests updates from the server instead of waiting for
191 the server to respond to the original import request. This changes allows
192 for incremental progress updates in the browser client.
197 This adds a new database table vandelay.session_tracker for tracking
198 in-progress vandelay upload activity. A new tracker row is added for
199 each of "upload", "enqueue", and "import" actions, linked for a given
200 session by the value stored in the "session_key" field.
202 The table tracks other potentially useful data, like the staff member
203 and workstation where the action was performed.
207 Users of NGINX as a reverse proxy may need to set a suitable
208 `client_max_body_size` value in the NGINX configuration so that large
209 MARC record uploads are not truncated. Note that this would have
210 always been necessary, but since this feature allows larger files
211 to be more reliably queued and imported, the need to set `client_max_body_size`
212 became more apparent.
217 Support for Last Inventory Date
218 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
219 Evergreen now provides an option to add an inventory date to items to facilitate
220 the process of performing inventory in libraries. Staff can add an inventory
221 date to an item in one of the following ways:
222 * From the check in screen, there is now an Update Inventory check in modifier.
223 When selected, scanned barcodes will have the current date/time added as the
224 inventory date while the item is checked in.
225 * From the Item Status screen, an action is available to add the current
226 date/time as the inventory date to selected items.
228 This new feature will also store the workstation that was used when the
229 inventory date was updated.
233 Parallel Ingest with pingest.pl
234 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
235 A program named pingest.pl is now installed to allow faster bibliographic record
236 ingest. It performs ingest in parallel so that multiple batches can
237 be done simultaneously. It operates by splitting the records to be
238 ingested up into batches and running all of the ingest methods on each
239 batch. You may pass in options to control how many batches are run at
240 the same time, how many records there are per batch, and which ingest
243 NOTE: The browse ingest is presently done in a single process over all
244 of the input records as it cannot run in parallel with itself. It
245 does, however, run in parallel with the other ingests.
249 pingest.pl accepts the following command line options:
252 The server where PostgreSQL runs (either host name or IP address).
253 The default is read from the PGHOST environment variable or
257 The port that PostgreSQL listens to on host. The default is read
258 from the PGPORT environment variable or 5432.
261 The database to connect to on the host. The default is read from
262 the PGDATABASE environment variable or "evergreen."
265 The username for database connections. The default is read from
266 the PGUSER environment variable or "evergreen."
269 The password for database connections. The default is read from
270 the PGPASSWORD environment variable or "evergreen."
273 Number of records to process per batch. The default is 10,000.
276 Max number of worker processes (i.e. the number of batches to
277 process simultaneously). The default is 8.
284 Skip the selected reingest component.
287 Start processing at this record ID.
290 Stop processing when this record ID is reached.
293 Read record IDs to reingest from standard input. This option
294 conflicts with --start-id and/or --end-id.
297 Stop processing after this many total seconds have passed. The
298 default is to run until all records have been processed.
305 View Authority Record by Database ID
306 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
308 A new interface allows catalogers to retrieve a specific
309 authority record using its database ID. Catalogers can
310 find those IDs in subfield $0 of matching fields in
311 bibliographic records.
313 To use the new authority record viewer:
315 . Click *Cataloging -> Retrieve Authority Record by ID*.
316 . Type in the ID number of the authority record you are
317 interested in. Don't include any prefixes, just the ID
320 . View or edit the authority record as needed.
331 Circulation policies in Evergreen can now be configured to automatically renew
332 certain items checked out on patron accounts. Circulations will be renewed
333 automatically up to a custom limit (the `max_auto_renewal` field) and patrons
334 will not need to log in to their OPAC accounts or ask library staff to manually
337 Two new action triggers have been added to Evergreen that permit the Auto-Renew
338 feature. They can be found, configured, and enabled in Administration>Local
339 Administration>Notifications/Action Triggers. They are named **Autorenew** and
342 The **Autorenew** A/T definition uses the `checkout.due` hook to automatically
343 validate and renew (in the reactor) circulations on the day they are due,
344 grouped by user. The output events of this definition is is the input used by
345 the related **AutorenewNotify** A/T that simply uses a new hook called
346 `autorenewal` to notify patrons via email of their currently due or
349 In the webstaff's Patron Items Out page, the new column `AutoRenewalsRemaining`
350 indicates how many autorenewals are available for a particular circulation.
356 Emergency Closing Handler
357 ^^^^^^^^^^^^^^^^^^^^^^^^
359 Staff are provided with interfaces and mechanisms to create library closings that, in addition to affecting future circulation and booking due dates, and hold shelf expirations, will automatically move existing circulation and booking due dates and hold shelf expiration times. This new functionality is conceptually described as Emergency Closings and business logic implementing it as the Emergency Closing Handler. It contains additions and adjustments to the user interface, business logic, and database layers. Access to this functionality is available through the Closed Dates Editor interface in the staff client which has been ported to AngularJS.
364 This development has created new business logic code to inspect, in real time, existing circulation, booking, and hold records, and modify such date and time stamps so that the circulation, booking, or hold will end in the same state it would have if the closing had existed at the time the circulation or booking occurred, or the hold was placed and captured. Of specific note, hourly loans will have their due date adjusted to be the end of the day following the closing.
366 When the Emergency Closing is saved, any fines accrued during the closing may be voided, as settings dictate, with the exception of circulations that have been marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE circulations with due dates that fall within the Emergency Closing, no fine adjustment will be applied. Emergency Closing processing is permanent, and cannot be rolled back.
368 This functionality is explicitly initiated by staff action. If staff do not request an Emergency Closing, existing circulations, bookings, and holds will not be processed and adjusted. However, if staff request any Closing that starts nearer in time than the length of the longest circulation duration configured for use in the Evergreen instance they will be prompted with the option to create the closing as an Emergency Closing.
370 Action/Trigger hooks have been created for circulations and bookings that are adjusted by the Emergency Closing Handler. These will facilitate the creation of notifications to patrons that the due date has changed and to alert them to potential changes in accrued fines.
372 Booking start dates are explicitly ignored in this implementation. Because an Emergency Closing is, by its nature, an unexpected event, it will be up to staff to address any bookings which intersect with a new Emergency Closings. Reports can be used to identify booking start dates that overlap with a closing and that may require staff intervention.
374 Staff requesting and Emergency Closing must have the new EMERGENCY_CLOSING permission.
375 Some text describing the feature.
381 Patron Preferred Name and Name Search Keywords
382 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
387 Adds a new set of patron preferred name fields for prefix, first,
388 middle, last, and suffix allowing patrons to provide preferred name
389 information. Preferred names are optional and each acts as an overlay
390 to the analogous primary name field, making it possible to provide
391 preferred name values for individual fields.
393 For example, a patron named William Erickson may have a preferred first
394 name (pref_first_given_name) of Bill, in which case the preferred name
395 would be Bill Erickson. Note a preferred last name is not required in
396 this case as the code uses primary name values as defaults when not
397 replaced with a preferred version.
399 * Patrons will see primary names displayed in the catalog when set.
400 * Staff will see both primary name and preferred name in the patron
402 * Patron searches for any given name field will search both the primary
403 and preferred name data.
404 * Preferred name fields are available in Action/Trigger templates and
405 are present in various patron-focused print templates.
410 Adds a new field to store miscellaneous patron name search terms. These
411 values are only for searching and do not appear in any interfaces, apart
412 from the patron summary side bar and the patron edit UI.
414 Included is a new search field in the patron search UI which searches
415 keyword values and all other name fields. It's essentially a global patron
424 Disabling of legacy XUL staff client
425 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
426 The legacy XUL staff client is no longer supported in Evergreen
427 3.2.x and the server-side installation no longer supports a
428 direct connection by a version XUL client by default. All
429 users of Evergreen 3.2.x are strongly urged to complete their
430 switch to the web staff client as part of upgrading to 3.2.x.
432 Evergreen administrators who for some reason continue to wish
433 to deploy the XUL staff client can do so at their risk by
434 supplying `STAFF_CLIENT_STAMP_ID` during the `make install` step
435 and using `make_release` to create installers for the staff client.
436 However, no community support will be provided for the XUL client.
441 Permission Group Display Entries
442 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
443 In some cases, it is useful to have the ability to reorder permission, or to make
444 only specific groups available in the permission group selector for specific
445 Org Units. An interface has been made available to allow this.
447 Group Tree Display Entry Interface
448 ++++++++++++++++++++++++++++++++++
450 Permission Group Display Entries can be reordered, added, or removed via
451 _Administration -> Local Admin -> Permission Tree Display Entries_.
452 Select the Org Unit you wish to edit the entries in.
454 Entries may be added using the Add functionality, creating entries based
455 on permission groups that have not been added to the tree for the Org
456 Unit you wish to add them to.
458 image::media/pgtde_01.png[Group Tree Display Entry Admin UI]
462 Moving an entry will shift its position up or down in the patron profile
463 selector for a given Org Unit.
466 * Press either the *Move Up* or *Move Down* button. The entry will be
467 moved up or down, accordingly.
468 * Click *Save* to save your edits.
470 NOTE: You may only move up or down entries that have sibling entries.
474 If you want a particular Org Unit to not have access to specific
475 entries, you may remove an entry. Removing an entry will remove it from
476 view. The entry will be removed from the database.
478 * Select an entry and press the *Remove* button.
482 You may add entries from permission groups that are not currently
483 reflected in the permission group tree. This is useful for moving
484 entries to different parents, or making them root entries.
486 image::media/pgtde_02.png[Add Entry modal]
488 * If desired, select an entry to be used as the parent entry.
489 * Press the *Add* button.
490 * Select a permission group from the dropdown.
491 * If you've selected a parent entry, you may check the *Add Root Entry*
492 box to override that parent and add the entry on the root level.
493 * If you did not select a parent entry, the entry will be added on the root
498 Browser Client Settings & Preferences Stored on the Server
499 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
500 Browser client settings and preferences that should persist over time are
501 now stored as settings on the server. This allows settings to follow
502 users and workstations and reduces problems associated with losing settings
503 as a result of clearing browser data.
505 The browser client honors setting values stored as user settings, workstation
506 settings, and org unit settings, depending on which setting types are
512 * No setting can be both a user and workstation setting. They are mutually
514 * Any setting can be an org unit setting in addition to being a user or
520 Read-only settings are useful for defining values that staff can use but
521 not modify. For example, admins may wish to prevent users from locally
522 modifying the grid configuration for a given interface so it remains
523 consistent for all users.
525 A setting is read-only when an org unit setting type exists (regardless of
526 whether a value is applied) and no user or workstation setting type exists.
528 Server-Stored Workstation Settings Workstation Admin View
529 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
531 There's a new "Server Workstation Prefs" tab to the stored preferences
532 workstation admin interface. From here, users can view which
533 preferences are stored as server-stored workstation preferences and
534 delete select values.
539 A new permission APPLY_WORKSTATION_SETTING has been added to control who
540 may apply values to workstation settings. Use something like the following
541 to apply the permission to all staff accounts (mileage may vary):
544 --------------------------------------------------------------------------
545 INSERT INTO permission.grp_perm_map (grp, perm, depth)
547 (SELECT id FROM permission.grp_tree WHERE name = 'Staff'), -- name may vary
548 (SELECT id FROM permission.perm_list WHERE code = 'APPLY_WORKSTATION_SETTING'),
551 --------------------------------------------------------------------------
553 Workstation setting types matching values previously stored in the browser
554 (via localStorage or Hatch) are created as part of this feature. During
555 upgrade, admins should consider whether any of these new setting types
556 should be transferred to user and/or org unit settings instead. Setting
557 type changes can be made at any time, but when a setting type is deleted
558 all of its data is deleted, so a change in type means re-applying the
559 settings in the browser client.
561 Values stored in the browser will automatically migrate to server settings
562 as each setting is accessed in the browser client. Once migrated, the
563 in-browser copies are deleted.
565 If a setting type does not exist where the browser expects one, the
566 value is stored in-browser instead and a warning is issued in the console.
569 More consistent terminology in the client
570 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
571 Terminology has been updated in the staff client so that we consistently use
572 the same name to describe the same thing. The following updates have been made:
574 * The term 'item' is now consistently used to describe the barcoded entity
575 that had been previously been called both an 'item' and a 'copy'. As a result,
576 we now use the terms 'item buckets', 'item tags', and 'item alerts'.
577 * The term 'volume' is no longer used in the client, with the exception of
578 serials, where the term is used to describe serial volumes. The term 'call
579 number' will replace volume in most other places.
580 *'Holdings' is a more general term used to describe a combination of items
582 * The term 'Shelving Location' is used consistently in favor of 'Copy
593 Batch Actions In the Public Catalog
594 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
595 The public catalog now displays checkboxes on the bibliographic and
596 metarecord constituents results pages. Selecting one or more titles
597 by using the checkboxes will dynamically add those title to the
598 temporary list, which is now renamed the cart.
600 Above the results lists there is now a bar with a select-all checkbox,
601 a link to the cart management page that also indicates the number of
602 of titles in the cart, and a link to remove from the cart titles that
603 are selected on the currently displayed results page.
605 The search bar now includes an icon of a cart and displays the number
606 of titles currently in the cart. Next to that icon is a menu of cart
609 The cart actions available are Place Hold, Print Title Details,
610 Email Title Details, Add Cart to Saved List, and Clear Cart. In the
611 web staff client, the cart actions also include Add Cart to Bucket.
612 When an action is selected from this menu, the user is given an
613 opportunity to confirm the action and to optionally empty the cart
614 when the action is complete. The action is applied to all titles
617 Clicking on the cart icon brings the user to a page listing the
618 titles in the cart. From there, the user can select specific records
619 to request, print, email, add to a list, or remove from the cart.
621 The list of actions on the record details page now provides separate
622 links for adding the title to a cart or to a permanent list.
624 The permanent list management page in the public catalog now also
625 includes batch print and email actions.
627 Additional information
628 ++++++++++++++++++++++
629 * The checkboxes do not display on the metarecord results page, as
630 metarecords currently cannot be put into carts or lists.
631 * The checkboxes are displayed only if JavaScript is enabled. However,
632 users can still add items to the cart and perform batch actions on
633 the cart and on lists.
634 * A template `config.tt2` setting, `ctx.max_cart_size`, can be used to
635 set a soft limit on the number of titles that can be added to the
636 cart. If this limit is reached, checkboxes to add more records to the
637 cart are disabled unless existing titles in the cart are removed
638 first. The default value for this setting is 500.
643 This patch adds the the public catalog two routes that return JSON
646 * `GET /eg/opac/api/mylist/add?record=45`
647 * `GET /eg/opac/api/mylist/delete?record=45`
649 The JSON response is a hash containing a mylist key pointing to the list
650 of bib IDs of contents of the cart.
652 The record parameter can be repeated to allow adding or removing
653 records as an atomic operation. Note that this change also now available
654 to `/eg/opac/mylist/{add,delete}`
656 More generally, this adds a way for EGWeb context loaders to specify that
657 a response should be emitted as JSON rather than rendering an HTML
658 page using `Template::Toolkit`.
660 Specifically, if the context as munged by the context loader contains
661 a `json_response` key, the contents of that key will to provide a
662 JSON response. The `json_response_cookie` key, if present, can be used
663 to set a cookie as part of the response.
665 Template Toolkit processing is bypassed entirely when emitting a JSON
666 response, so the context loader would be entirely responsible for
667 localization of strings in the response meant for direct human
673 New class for searchbar when on the homepage
674 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
676 This adds the `.searchbar-home` class to the div that
677 contains the searchbar when on the homepage. This allows
678 sites to customize the searchbar differently on the
679 homepage than in other places the
680 search bar appears (for example, offering a large,
681 Google-style search bar on the homepage only).
686 To make customization easier, the username hint on the OPAC login page ("Please
687 include leading zeros...") has been moved to a separate TT2 template. If you
688 have customized the hint text, you will need to add your modifications to
695 The Evergreen project would like to acknowledge the following
696 organizations that commissioned developments in this release of
699 * BC Libraries Cooperative
700 * Consortium Of Ohio Libraries
702 * Georgia Public Library Service
703 * Indiana State Library
704 * Lake Agassiz Regrional Library
706 * North Texas Library Consortium
707 * Northwest Regional Library
708 * Pennsylvania Integrated Library System
709 * South Carolina State Library
711 We would also like to thank the following individuals who contributed
712 code, translations, documentations patches and tests to this release of
717 * Andrea Buntz Neiman
726 * Blake Graham-Henderson
727 * Francisco J Guel-Mendoza
745 We also thank the following organizations whose employees contributed
748 * BC Libraries Cooperative
751 * Equinox Open Library Initiative
752 * Government of Manitoba
753 * Kenton County Public Library
754 * King County Library System
755 * Linn-Benton Community College
759 We regret any omissions. If a contributor has been inadvertently
760 missed, please open a bug at http://bugs.launchpad.net/evergreen/
projects / Evergreen.git / blob