Docs: Adding to 3.1.2 release notes
[working/Evergreen.git] / docs / RELEASE_NOTES_3_1.adoc
1 Evergreen 3.1 Release Notes
2 ===========================
3 :toc:
4 :numbered:
5
6
7 Evergreen 3.1.2
8 ---------------
9
10 This release contains bug fixes improving on Evergreen 3.1.1.   Note that
11 all bug fixes refer to the web staff client unless otherwise specified.
12
13 Bug fixes
14 ~~~~~~~~~
15
16 Cataloging
17 ^^^^^^^^^^
18
19 * The MARC editor now handles 008 fields better.
20 * Adds spaces between subfields when suggesting a call
21 number for a new volume.
22 * MarcXML exports from the MARC Batch Import/Export ->
23 Export Records screen now downloads the file, rather than opening
24 it in the browser.
25 * The Item Status Circulation Library column now displays a 
26 shortname rather than the full library name.
27 * The Item Status Remaining Renewals column now displays
28 correctly.
29 * The Item Status now has a "Last Renewal Workstation" column
30 available.
31 * Fixes the circulation counts displayed in Item Status Details.
32 * Removes an error that got thrown in the Holdings View when a call number
33 contains no copy.
34 * Fixes an issue where multiple copies with different values for required
35 statistical categories could not be edited and saved in batch.
36 * Add an option to remove floating in the copy editor.
37 * Fixes an issue with the floating dropdown in the copy editor.
38 * Reduces the number of API calls that the MARC Editor requires.
39 * The order of the Z39.50 servers on the Z39.50 import screen
40 no longer relies on capitalization.
41
42 Circulation
43 ^^^^^^^^^^^
44
45 * Fixes an issue that prevented the offline patron registration
46 screen from loading.
47 * Fixes an issue with searching patrons by permission group.
48 * Staff members can now manually override the patron juvenile
49 flag value, regardless of the patron's date of birth.
50 * Checkboxes on patron registration screen are now properly aligned
51 with other fields.
52 * The user permission group dropdowns in the patron registration,
53 edit, and search interfaces now have scrollbars.
54 * The check-in screen now includes a copy status column.
55 * The Merge Patrons interface now displays the date of birth.
56 * The payment button on patron bills screen is now inactive if the
57 Payment Received field is blank.
58 * The Bill History receipt now includes a Finish date and a Last
59 Payment date.
60 * When a patron summary contains an image of the patron,
61 that image tag now has a null alt attribute to remove it from
62 the flow of a screen reader.
63 * Corrects an issue that caused the transit dialog to show the
64 wrong branch.
65 * Restores the call number prefix and suffix fields to the holds
66 pull list.
67 * The documentation at the top of the hold shelf slip template
68 adds `patron.alias`.
69 * The cursor in the in-house use screen now automatically goes
70 to the barcode field.
71 * Add support for converting change to patron credit in the patron bills
72 interface, consistent with the XUL feature.
73 * Fixes a bug that caused pickup/request library fields to be
74 blank sometimes.
75 * Fixes a bug in the offline org unit tree.
76
77 Command-line system administration
78 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
79
80 * The novelist entry in `eg_vhost.conf` includes two new
81 parameters.
82 * Corrects an issue with the `--max-sleep` argument on the
83 `action_trigger_runner.pl` support script.
84 * Corrects an issue with how the `eg_pbx_allocator.pl` script
85 detects an existing lock file.
86 * The 3.0.2-3.0.3 upgrade script disables triggers before
87 recalculating bib visibility.
88
89 Public catalog
90 ^^^^^^^^^^^^^^
91
92 * Fixes an issue that caused records with located URIs to be
93 retrieved in Copy Location and Copy Location Group searches.
94 * Fixes an error message that appeared in the search box
95 in the public catalog while placing hold after an advanced search.
96 * Restores the display of copy information for the user's
97 preferred library in the public catalog.
98 * Author and contributor names are no longer highlighted in 
99 search results when the user has turned off highlighting.
100 * Fixes regression errors in the search results page.
101 * Removes redundant call numbers from the Show More Details
102 search results.
103
104 Serials
105 ^^^^^^^
106
107 * Fixes an issue that prevented users from searching for
108 receivable issues using Database ID or ISSN in the Serials
109 Batch Receive interface.
110
111 General
112 ^^^^^^^
113 * Pins AngularJS support to version 1.6, which prevents unsupported
114 AngularJS versions (such as 1.7) from breaking the build process.
115 * Adds some padding to the bottom of Web Client interfaces.
116
117 Acknowledgements
118 ~~~~~~~~~~~~~~~~
119 We would like to thank the following individuals who contributed code,
120 tests and documentation patches to the 3.1.2 point release of
121 Evergreen:
122
123 * John Amundson
124 * Jason Boyer
125 * Galen Charlton
126 * Garry Collum
127 * Dawn Dale
128 * Jeff Davis
129 * Bill Erickson
130 * Lynn Floyd
131 * Rogan Hamby
132 * Kyle Huckins
133 * Sam Link
134 * Jeanette Lundgren
135 * Kathy Lussier
136 * Katie G. Martin
137 * Terran McCanna
138 * Dan Pearl
139 * Mike Rylander
140 * Laura Sachjen
141 * Jane Sandberg
142 * Chris Sharp
143 * Ben Shum
144 * Remington Steed
145 * Jason Stephenson
146 * Josh Stompro
147 * Cesar Velez
148 * Dan Wells
149 * Bob Wicksall
150
151
152
153 Evergreen 3.1.1
154 ---------------
155 This release contains bug fixes improving on Evergreen 3.1.0.
156
157 * Fixes a performance issue with the Patron Billing History screen and
158 other screens that cause Flattener.pm to re-create joins
159 unnecessarily.
160 * Fixes an issue that prevented patron alerts from showing to staff at
161 other libraries.
162 * Corrects the "Holdable" attribute display on the Item Status detailed
163 view.
164 * Fixes the ability to delete multiple copies from Item Status.
165
166 Acknowledgements
167 ~~~~~~~~~~~~~~~~
168 We would like to thank the following individuals who contributed code,
169 tests and documentation patches to the 3.1.1 point release of
170 Evergreen:
171
172 * Jason Boyer
173 * Bill Erickson
174 * Morkor Quarshie
175 * Jane Sandberg
176 * Remington Steed
177 * Jason Stephenson
178 * Kevin Tran
179 * Dan Wells
180
181
182 3.1.0 Upgrade Notes
183 -------------------
184 Like many major Evergreen upgrades, 3.1 requires a full reingest of your
185 bibliographic records before the system is usable again.  While a basic reingest
186 is included at the end of the upgrade script, it happens after the main
187 COMMIT, so it is safe to cancel that and run the required reingest as you see
188 fit (e.g. via pingest.pl).
189
190
191 3.1.0 New Features
192 ------------------
193
194 Administration
195 ~~~~~~~~~~~~~~
196
197 New Latency Tester Tool
198 ^^^^^^^^^^^^^^^^^^^^^^^
199 The Evergreen Web Staff Client now includes a section called *Tests* linked from
200 *Administration -> Workstation*. The *Tests* page houses a simple tool
201 that can be used to test the latency of the websocket connection between the
202 client and the server (via the `opensrf.echo` service).
203
204 This page displays which Evergreen host server is being queried. Upon hitting
205 the blue "Start Test" button for the first time, it will issue 10 sequentially
206 fired requests in order to get a solid initial average. Clicking the button a
207 second time will take one more measurement and recalculate the average
208 latency. The results can be copied to clipboard for troubleshooting purposes
209 and also cleared from display.
210
211 marc_export --uris option
212 ^^^^^^^^^^^^^^^^^^^^^^^^^
213 The marc_export support script now has a `--uris` option (short form:
214 `-u`) to export records with located URIs (i.e. electronic resources).  When
215 used by itself, it will export only records that have located URIs.  When
216 used in conjunction with `--items`, it will add records with located URIs
217 but no items/copies to the output.  If combined with a `--library` or
218 `--descendants` option, this option will limit its output to those
219 records with URIs at the designated libraries.  The best way to use
220 this option is in combination with the `--items` and one of the
221 `--library` or `--descendants` options to export *all* of a library's
222 holdings both physical and electronic.
223
224
225 Architecture
226 ~~~~~~~~~~~~
227
228 Sample Data Includes Surveys
229 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
230 The Concerto sample data set now includes patron surveys, questions,
231 answers, and responses.
232
233 Virtual Index Definitions
234 ^^^^^^^^^^^^^^^^^^^^^^^^^
235 The practical purpose of Virtual Index Definitions is to supply an Evergreen
236 administrator with the ability to control the weighting and field inclusion of
237 values in the general keyword index, commonly referred to as "the blob,"
238 without requiring tricky configuration that has subtle semantics, an
239 over-abundance of index definitions which can slow search generally, or the
240 need to reingest all records on a regular basis as experiments are performed
241 and the configuration refined. Significant results of recasting keyword indexes
242 as a set of one or more Virtual Index Definitions will be simpler search
243 configuration management, faster search speed overall, and more practical
244 reconfiguration and adjustment as needed.
245
246 Previously, in order to provide field-specific weighting to
247 keyword matches against titles or authors, an administrator must duplicate many
248 other index definitions and supply overriding weights to those duplicates. This
249 not only complicates configuration, but slows down record ingest as well as
250 search. It is also fairly ineffective at achieving the goal of weighted keyword
251 fields. Virtual Index Definitions will substantially alleviate the need for
252 these workarounds and their consequences.
253
254   * A Virtual Index Definition does not require any configuration for
255 extracting bibliographic data from records, but instead can become a sink for
256 data collected by other index definitions, which is then colocated together to
257 supply a search target made up of the separately extracted data. Virtual Index
258 Definitions are effectively treated as aggregate definitions, matching across
259 all values extracted from constituent non-virtual index definitions.  They can
260 further make use of the Combined class functionality to colocate all values in a
261 class together for matching even across virtual fields.
262
263   * Configuration allows for weighting of constituent index definitions that
264 participate in a Virtual Index Definition. This weighting is separate from the
265 weighting supplied when the index definition itself is a search target.
266
267   * The Evergreen QueryParser driver returns the list of fields actually
268 searched using every user-supplied term set, including constituent expansion
269 when a Virtual Index Definition is searched. In particular, this will facilitate
270 Search Term Highlighting described below.
271
272   * Stock configuration changes make use of pre-existing, non-virtual index
273 definitions mapped to new a Virtual Index Definition that implements the
274 functionality provided by the `keyword|keyword` index definition. The
275 `keyword|keyword` definition is left in place for the time being, until more data
276 can be gathered about the real-world effect of removing it entirely and
277 replacing it with Virtual Index Definition mappings.
278
279   * New system administration functions will be created to facilitate
280 modification of Virtual Index Definition mapping, avoiding the need for a full
281 reingest when existing index definitions are added or removed from a virtual
282 field.
283
284 Increased use of Metabib Display Fields
285 +++++++++++++++++++++++++++++++++++++++
286 We use Metabib Display Fields (newly available in 3.0) to render catalog search
287 results, intermediate metarecord results, and record detail pages. This requires
288 the addition of several new Metabib Display Field definitions, as well as Perl
289 services to gather and render the data.
290
291 We also use more Metabib Display Fields in the client. As a result,
292 bibliographic fields will display in proper case in more client interfaces and
293 in Evergreen reports.
294
295 Interfaces
296 ++++++++++
297 A new AngularJS "MARC Search/Facet Fields" interface has been created to replace
298 the Dojo version, and both have been extended to support Virtual Index
299 Definition data supplier mapping and weighting.
300
301 Settings & Permissions
302 ++++++++++++++++++++++
303 The new Virtual Index Definition data supplier mapping table,
304 `config.metabib_field_virtual_map`, requires the same permissions as the
305 MARC Search/Facet Fields interface: CREATE_METABIB_FIELD, UPDATE_METABIB_FIELD,
306 DELETE_METABIB_FIELD, or ADMIN_METABIB_FIELD for all actions
307
308 Backend
309 +++++++
310 There now exist several new database tables and functions primarily in support
311 of search highlighting. Additionally, the QueryParser driver for Evergreen has
312 been augmented to be able to return a data structure describing how the search
313 was performed, in a way that allows a separate support API to gather a
314 highlighted version of the Display Field data for a given record.
315
316 Default Weights
317 +++++++++++++++
318 By default, the following fields will be weighted more heavily in keyword
319 searches. Administrators can change these defaults by changing the values in the
320  "All searchable fields" virtual index in the "MARC Search/Facet Fields"
321 interface.
322
323   * Title proper
324   * Main title (a new index limited to the words in the 245a)
325   * Personal author
326   * All subjects
327
328 In addition, note indexes and the physical description index will receive
329 less weight in default keyword searches.
330
331 Re-ingest or Indexing Dependencies
332 ++++++++++++++++++++++++++++++++++
333 With the addition and modification of many Index Definitions, a full reingest is
334 recommended.  However, search will continue to work as it did previously
335 for those records that have not yet been reingested. Therefore a slow, rolling
336 reingest is recommended.
337
338 Performance Implications or Concerns
339 ++++++++++++++++++++++++++++++++++++
340 Because the Metabib Display Fields infrastructure will eventually replace
341 functionality that is significantly more CPU-intensive in the various forms of
342 XML parsing, XSLT transformation, XPath calculation, and
343 Metabib Virtual Record construction, it is expected that the overall CPU load
344 will be reduced by this development, and ideally the overall time required to
345 perform and render a search will likewise drop. It is unlikely that the speed
346 increase will be visible to users on a per-search basis, but that search in
347 aggregate will become a smaller consumer of resources.
348
349
350 Cataloging
351 ~~~~~~~~~~
352
353 Track Record Merges
354 ^^^^^^^^^^^^^^^^^^^
355 When 2 or more bib records are merged, all records involved are stamped
356 with a new `merge_date` value.  For any bib record, this field indicates
357 the last time it was involved in a merge.  At the same time, all
358 subordinate records (i.e. those deleted as a product of the merge) are
359 stamped with a `merged_to` value indicating which bib record the source
360 record was merged with.
361
362 In the browser client bib record display, a warning alert now appears
363 along the top of the page (below the Deleted alert) indicating when a
364 record was used in a merge, when it was merged, and which record it was
365 merge with, rendered as a link to the target record.
366
367
368 Circulation
369 ~~~~~~~~~~~
370
371 Alternate Patron Hold Pickup
372 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
373 This feature adds a bit of convenience to a common task: checking out
374 an item on hold to another patron (typically a family member or helper).
375
376 When you checkout the item, you will get a pop-up window with warnings associated
377 with this item.  The "ITEM_ON_HOLDS_SHELF" message is now expanded to
378
379  * Let you know the name of the person who had placed the hold.
380  * Give you the option (in the form of a checkbox) of cancelling the
381    hold placed by the above-named patron.  (Checked = Cancel the hold;
382    Unchecked = Leave the hold in place)
383
384 The initial value of the checkbox is derived from the
385 `circ.clear_hold_on_checkout` organizational setting.
386
387 If the operator has CANCEL_HOLD privilege, then if the checkbox is checked and
388 the checkout is allowed to proceed, the hold will be cancelled with a note that
389 the item was checked out to another patron.
390
391 This feature is available in the browser-based staff client.
392
393 New Patron Billing Statement
394 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
395 The Evergreen web staff client now includes a patron billing statement,
396 which summarizes a patron's bills, credits and payments in a familiar
397 layout.  This can be found on the "Statement" tab of the Patron Bill
398 Details page. (From the Patron Bills page, double-click a row to view
399 its details, or choose "Full Details" from the Actions menu.)
400
401 Enhanced Billing Timestamp Support
402 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
403 Previously, billings had to make do with a single timestamp attempting
404 to fill two different roles.  In the case of an overdue fine, the
405 timestamp represented the *end* of the fine period for that billing,
406 while for all other fines, the timestamp was merely the time the bill
407 was created.  This setup generally worked, but not without confusion,
408 and limited our ability to understand and process the data.
409
410 Billings will now have up to three timestamps: a create date, and when
411 applicable, a fine period start and a fine period end.  This clarifies
412 and simplifies things like backdating, retrospective fine generation,
413 account balancing for negative balance avoidance, and billing timeline
414 views.
415
416 Copy Alerts and Suppression Matrix
417 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
418 The Copy Alerts feature allows library staff to add customized alert
419 messages to copies. The copy alerts will appear when a specific event
420 takes place, such as when the copy is checked in, checked out, or
421 renewed. Alerts can be temporary or persistent: temporary alerts will be
422 disabled after the initial alert and acknowledgement from staff, while
423 persistent alerts will display each time the alert event takes place.
424 Copy Alerts can be configured to display at the circulating or owning
425 library only or, alternatively, when the library at which the alert
426 event takes place is not the circulating or owning library.  Copy Alerts
427 can also be configured to provide options for the next copy status that
428 should be applied to an item.  Library administrators will have the
429 ability to create and customize Copy Alert Types and to suppress copy
430 alerts at specific org units.
431
432 Copy alerts can be added via the volume/creator and the check in,
433 check out, and renew pages.  Copy alerts can also be managed at the
434 item status page.
435
436 Copy alert types can be managed via the Copy Alert Types page in
437 Local Administration, and suppression of them can be administered
438 via the Copy Alert Suppression page under Local Administration.
439
440 Place Multiple Holds At Once
441 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
442 Users with the appropriate permissions now have the ability to place multiple
443 title/metarecords holds at once. This feature is especially beneficial for book
444 clubs and reading groups, which need to place holds on multiple copies of a
445 title.
446
447 In order to use the feature:
448
449   * Set the _Maximum number of duplicate holds allowed_ Library Setting
450     (`circ.holds.max_duplicate_holds`) to a number higher than 1
451   * Log in as a user with the CREATE_DUPLICATE_HOLDS
452
453 When placing a title or metarecord hold, a _Number of copies_ field will
454 display for these users. This field is not available when placing part, volume
455 or copy holds.
456
457 This feature does not change the way in which the system fills holds. The
458 multiple holds will fill in the same way that they would if the user had placed
459 multiple holds separately.
460
461 New Notice Columns in Items Out Grid
462 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
463 The grid in the patron "items out" page in the Evergreen web staff client has two new
464 columns indicating the number of notifications generated for a given loan and the date of
465 the most recent notification. These columns will allow circulation staff to better respond to
466 patron questions about whether they were sent notification about an overdue item.
467
468 The columns are based on the number of completed Action Trigger events on the
469 loan that have a 'checkout.due' hook. In other words, they would include overdue
470 and courtesy notices.
471
472 A new library setting, "Exclude Courtesy Notices from Patrons Itemsout Notices Count",
473 if set will cause the notice count and date fields to exclude courtesy notices.
474
475 Patron Email Addresses Now Clickable In Web Staff Client
476 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
477 Adds a mailto link to the patron's email in their profile so it can
478 be clicked to send and email to the patron. No new settings or
479 permissions are included in this feature.
480
481 Pickup Library for Staff-placed Holds
482 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
483 Adds a new library setting, _circ.staff_placed_holds_fallback_to_ws_ou_,
484 that helps determine the hold pickup library in cases where patrons don't
485 have a preferred hold pickup library in their account and a staff member
486 is placing the hold on their behalf.
487
488   * When this setting is true and the patron doesn't have a preferred
489   library listed, the hold pickup library will default to the
490   workstation's organizational unit.
491   * When this setting is false and the patron doesn't have a preferred
492   library listed, the hold pickup library will default to the
493   patron's home library.
494
495 Public Catalog
496 ~~~~~~~~~~~~~~
497
498 Search Term Highlighting
499 ^^^^^^^^^^^^^^^^^^^^^^^^
500 Evergreen now highlights search terms on the public catalog's main search
501 results page, the record detail page, and intermediate pages such as metarecord
502 grouped results page. Highlighting search terms will help the user determine why
503 a particular record (or set of records) was retrieved.
504
505 Highlighting of matched terms uses the same stemming used to accomplish the
506 search, as configured per field and class.
507
508 This feature will help the user more quickly determine the relevance of a
509 particular record by calling their attention to search terms in context. Lastly,
510 it will help familiarize the user with how records are searched, including which
511 fields are searched as well as exposing concepts like stemming.
512
513 You can turn off search term highlighting by uncommenting the line
514 `search.no_highlight = 1;` in `config.tt2`.
515
516 When highlighting is generally enabled, it may be turned on or off on a per-page
517 basis through the use of a UI component which will request the page again
518 without highlighting.
519
520 Highlighting of terms uses Template::Toolkit-driven CSS. A generic CSS class
521 identifying a highlighted term, along with CSS classes identifying the search
522 class and each search field are available for use for customization of the
523 highlighting. A stock CSS template is provided as a baseline upon which sites
524 may expand.
525
526
527 Copy Location Filter Displays for System Searches
528 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
529 The Shelving Location filter now displays on the advanced search page when
530 a search is scoped to a library system, not just to an individual branch. If
531 a library system is selected as the Search Library, the shelving location
532 limiter will display any shelving location that is owned by the selected system
533 or by the consortium. It will NOT display shelving locations owned by child
534 branches.
535
536 Multi-source Attributes
537 ^^^^^^^^^^^^^^^^^^^^^^^
538 We now allow record attribute definitions to extract data using more than
539 one strategy (XPath, tag+subfield, fixed field, etc.) as long as the values
540 from various sources would, after normalization, have the same shape.
541
542 Multilingual Search
543 +++++++++++++++++++
544 This change allows us to configure multilingual search, by extracting values
545 from both the 008 controlfield and the 041 datafield.  Because the values
546 in each can be normalized to the same controlled list (and, in practice, are
547 already from the same normalized value set), catalog searches can now use normal
548 boolean search semantics to find records with various combinations of
549 language attributes.
550
551 E.g., in the concerto test data:
552
553   * `keyword: piano item_lang(eng) item_lang(ita)`
554
555
556 Optional Display of Badges in Catalog
557 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
558 A new setting controls whether badges (popularity, etc.) are displayed
559 in the catalog. If you do not wish badges to be displayed, set the
560 `ctx.hide_badge_scores` setting to "true" in `config.tt2`.
561
562
563 Miscellaneous
564 ~~~~~~~~~~~~~
565
566 Fixes to patron name/username search indexes
567 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
568 When using pg_restore to restore an Evergreen database, some of the
569 indexes used to speed up patron searches on names and usernames
570 could be lost.
571
572 This release fixes the underlying issue and re-creates the indexes
573 in question.
574
575 Details
576 +++++++
577 When using pg_restore to restore an affected database, the
578 "unaccent" indexes on actor.usr would not be created due to an
579 unqualified function reference in `evergreen.unaccent_and_squash`.
580
581 The function will be replaced to resolve the search path issue,
582 and the following indexes on actor.usr will be dropped and then
583 re-created:
584
585   * actor_usr_first_given_name_unaccent_idx;
586   * actor_usr_second_given_name_unaccent_idx;
587   * actor_usr_family_name_unaccent_idx;
588   * actor_usr_usrname_unaccent_idx;
589
590 This will be done even if the indexes are already present, and may
591 take a few minutes on a database with many patrons.
592
593
594 3.1.0 Acknowledgments
595 ---------------------
596 The Evergreen project would like to acknowledge the following
597 organizations that commissioned developments in this release of
598 Evergreen:
599
600 * Albany Public Library (Oregon)
601 * Consortium of Ohio Libraries
602 * CW MARS
603 * Indiana State Library
604 * Georgia Public Library Service
605 * Hagerstown - Jefferson Township Library
606 * Linn-Benton Community College
607 * MassLNC
608 * Pennsylvania Integrated Library System
609 * Sage Library System
610 * Union County Public Library (Indiana)
611
612 We would also like to thank the following individuals who contributed
613 code, translations, documentations patches and tests to this release of
614 Evergreen:
615
616 * Eva Cerninakova
617 * Andi Chandler
618 * Galen Charlton
619 * Jeff Davis
620 * Bill Erickson
621 * Jeff Godin
622 * Rogan Hamby
623 * Angela Kilsdonk
624 * Sam Link
625 * Jeanette Lundgren
626 * Kathy Lussier
627 * Fares Othman
628 * Dan Pearl
629 * Mike Rylander
630 * Jane Sandberg
631 * Chris Sharp
632 * Ben Shum
633 * Remington Steed
634 * Jason Stephenson
635 * Kevin Tran
636 * Cesar Velez
637 * Dan Wells
638
639
640 We also thank the following organizations whose employees contributed
641 patches:
642
643 * Bibliomation
644 * British Columbia Libraries Cooperative
645 * Calvin College
646 * CW MARS
647 * Equinox Open Library Initiative
648 * Georgia Public Library Service
649 * Greater Clarks Hill Regional Library System
650 * Jordanian Library and Information Association
651 * King County Library System
652 * Knihovna Jabok
653 * Linn-Benton Community College
654 * MassLNC
655 * Sigio
656 * Traverse Area District Library
657
658 We regret any omissions.  If a contributor has been inadvertently
659 missed, please open a bug at http://bugs.launchpad.net/evergreen/
660 with a correction.