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