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