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