Simple typo fix in docs
[evergreen-library-system:evergreen-library-system.git] / docs / RELEASE_NOTES_2_6.txt
1 Evergreen 2.6 Release Notes
2 ===========================
3 :toc:
4 :numbered:
5
6 Upgrade notes
7 -------------
8
9 OPAC
10 ~~~~
11
12 TPAC library pages
13 ^^^^^^^^^^^^^^^^^^
14 Evergreen 2.5 introduced the `Library information URL` library setting to
15 associate a web page with a library. If set, this value was used as the target
16 of the library link in the copy table on the record details page. However, the
17 new default behavior is to link to the automatically generated TPAC library
18 page, which in turn links to the external web site.
19
20 If you wish to maintain the previous behavior, you can set the `Use external
21 library information URL` library setting to `True`.
22
23
24 Miscellaneous
25 ~~~~~~~~~~~~~
26
27 Removal of open-ils.ingest service
28 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
29 The open-ils.ingest service is no longer required, and has been
30 removed.
31
32 You should update your opensrf.xml file to remove references to
33 open-ils.ingest, and you may also wish to remove the
34 OpenILS/Application/Ingest.pm file from your Perl @INC path.
35
36 In opensrf.xml, remove the entire <open-ils.ingest> element from the
37 <apps> element, and remove <appname>open-ils.ingest</appname> from
38 any <activeapps> elements where it is present.
39
40 If you have the perldoc command installed, you can use the following
41 command to locate the path on disk of the Ingest.pm file, which is
42 no longer required and can be removed:
43
44 [source, bash]
45 -----------------------------------------------------------------
46 perldoc -l OpenILS::Application::Ingest
47 -----------------------------------------------------------------
48
49
50 New Features
51 ------------
52
53 Administration
54 ~~~~~~~~~~~~~~
55
56 Add granular settings for requiring staff initials for notes
57 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
58 There are now three separate library settings for controlling whether staff 
59 are required to input their initials when creating different types of notes.
60 See new library settings below.
61
62 Any pre-existing library setting for requiring staff initials are preserved 
63 during the upgrade process. After upgrading, you may choose to change the set
64 behavior for any of the three new settings.
65
66 New Library Settings
67 +++++++++++++++++++++
68  * Require staff initials for entry/edit of patron standing penalties and messages. (ui.staff.require_initials.patron_standing_penalty)
69  * Require staff initials for entry/edit of patron notes. (ui.staff.require_initials.patron_info_notes)
70  * Require staff initials for entry/edit of copy notes. (ui.staff.require_initials.copy_notes)
71
72
73 Cataloging
74 ~~~~~~~~~~
75
76 Enhancements to Evergreen's MARC Editor Concerning Fixed Fields
77 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
78 This work is a combination of two features. One provides suggested
79 values in a right-click context menus for fixed field values based on
80 the 'type' of the record being edited. The other provides a wizard to
81 help specifically with the Physical Characteristics of the record, i.e.
82 the 007 field.
83
84 Right-Click Context Menus
85 +++++++++++++++++++++++++
86 Users will be able to right-click on the value control for fixed fields
87 in the MARC Editor, and Evergreen will provide a menu from which the
88 user can select a possible value. This will work for fixed fields where
89 Evergreen already contains information from the Library of Congress's
90 MARC 21 standard.
91
92 Example:
93
94 image::media/ffer-right-click.png["Right-clicking the BLvl field"]
95
96 Evergreen already comes loaded with information from the Library of
97 Congress's MARC 21 standard on possible values for some fixed fields.
98
99 The following table shows which fixed fields for which 'Record Types'
100 have values already loaded into Evergreen.
101
102 ---------------------------------------------------------
103
104  Fixed Field |          Record Types
105 -------------+-----------------------------------
106  Audn        | {BKS,COM,REC,SCO,SER,VIS}
107  BLvl        | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
108  Form        | {BKS,MAP,MIX,REC,SCO,SER,VIS}
109  Lang        | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
110  LitF        | {BKS}
111  Type        | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
112
113
114 ---------------------------------------------------------
115
116 A 'Record Type' is itself a combination of the 'Type of Record' (fixed
117 field name: Type) and 'Bibliographic Level' (fixed field name: BLvl)
118 elements of the MARC leader (positions 06 and 07 respectively). You can
119 see a record's Record Type in the MARC Editor as shown in
120 this screenshot:
121
122 'Record Type':
123
124 image::media/ffer-record-type.png["This Record Type is REC"]
125
126 A user may add values to these fixed fields as well as to other fixed
127 fields through the MARC Coded Value Maps interface found under the Admin
128 -> Server Administration menu in the staff client. These are grouped by
129 Record Attribute Types (a superset of fixed fields) which have labels
130 such as 'Alph', 'Biog', 'Videorecording format', and 'Language'.
131
132 From LOC Fixed Fields documentation, 'Alph' is 'Original alphabet or
133 script of title', 'Biog' is 'Biography', 'Videorecording format' is from
134 the 007 field, 'Language' is positions 35-37 of the 008, and so on.
135 Other Record Attribute Types such as 'Author' are, of course, not fixed
136 fields at all.
137
138 When users add new values here, the right-click context menus of the
139 fixed fields in the MARC Editor will include those values.
140
141 All values added for any fixed field in the Coded Value Map will display
142 for any 'Record Type' that uses that fixed field.
143
144 Users of the MARC Editor always retain the option of leaving a fixed
145 field blank, entering the special values # or |, or entering a value not
146 provided by the right-click context menu.
147
148 Physical Characteristics Wizard
149 +++++++++++++++++++++++++++++++
150 By right-clicking on an existing or new 007 field in the MARC Editor, users
151 will be able to enter a wizard that leads them step-by-step through the
152 positions in that 007 field, telling them the significance of the current
153 position and providing a drop-down list of possible values.
154
155 Launching the Physical Characteristics Wizard:
156
157 image::media/ffer-open-wizard.png["Launching the Physical Characteristics Wizard"]
158
159 Choosing the Category of Material:
160
161 image::media/ffer-007-00.png["Choosing the Category of Material"]
162
163 Choosing a value for a later position:
164
165 image::media/ffer-007-smd.png["Choosing a value for a later position"]
166
167
168 marc_export script replacement
169 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
170 The `/openils/bin/marc_export` script is completely rewritten.  This
171 new version accepts all of the same command line options as the old
172 version as well as some new options.
173
174 The rewritten `marc_export` talks directly to your Evergreen database
175 and is a great deal faster than the previous version.  Because the new
176 script talks directly to the database, it needs to know how to
177 connect.  To facilitate this, a new option, `--store`, was added that
178 allows the user to specify one of three Evergreen storage backends to
179 use when exporting records.  The valid choices are `reporter`,
180 `cstore`, or `storage`.  The default of `reporter` should work in most
181 cases, but if you do have a separate reporter database and you know
182 you want to talk directly to your main production database, then you
183 will probably want to choose either `cstore` or `storage`.
184
185 In addition to the `--store` option, a `--since` option is also added
186 so that you can specify output of an update file of records changed,
187 added, and/or deleted since the given date.  The `--since` option uses
188 a fairly flexible date parser and can accept a wide range of date
189 formats including ISO 8601, man common date formats such as M/D/Y
190 (common in the US) or D/Mon/Y (with the first 3 characters or more of
191 the month spelled out), as well as several less common date formats.
192 Special date strings such as `yesterday`, `today`, `yesterday week`,
193 and `today week` are also supported.  For more information see the
194 VALID DATE FORMATS section of the `Date::Manip::Date` man page.
195 Available online here:
196
197 http://search.cpan.org/~sbeck/Date-Manip-6.42/lib/Date/Manip/Date.pod#VALID_DATE_FORMATS
198
199 There is one final difference between the new script and the old
200 `marc_export`.  The new script does not output progress as it
201 executes.  Many of the statistics that the script reported are not
202 readily available to the new script.  It was deemed better to just not
203 output any progress rather than to output something different from the
204 old program.  If your scripts parse the output from `marc_export`,
205 they will need to modified not to expect any.
206
207
208 Circulation
209 ~~~~~~~~~~~
210
211 Lost Item Billing: New Min/Max Price Settings
212 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
213 When an item is marked lost, the user is typically billed for the item.
214 In Evergreen, they can either be charged the amount recorded in the item
215 object, or if that value is blank (or zero), charged a default price
216 (controlled by settings).
217
218 In addition to these existing settings, now we can accommodate a range of
219 prices by saying the patron should be billed at least 'X' and not more
220 than 'Y'. This also allows you to effectively set a fixed price for all
221 lost items by setting min and max to the same amount.
222
223 New Org Unit Settings
224 +++++++++++++++++++++
225  * Minimum Item Price: circ.min_item_price
226  * Maximum Item Price: circ.max_item_price
227
228 New Permissions
229 +++++++++++++++
230  * UPDATE_ORG_UNIT_SETTING.circ.min_item_price
231  * UPDATE_ORG_UNIT_SETTING.circ.max_item_price
232
233
234 User Editor: "Update Expire Date" button
235 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
236 A new button labeled "Update Expire Date" is added in the user
237 editor next to expire date field. This button can be used to
238 re-calculate the user's expire date based on the current profile's
239 permission interval and today's date.
240
241 This is similar to how the expire date is populated when creating a
242 new user, or when changing the profile group.
243
244 This button simplifies the process of "renewing" a user, by
245 eliminating the requirement that staff manually enter a new expire
246 date.
247
248 A button is used here so that the updating of the expire date
249 remains an  intentional process, not one that happens upon any edit.
250
251
252 OPAC
253 ~~~~
254
255 Composite Record Attributes
256 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
257 With this feature we create an abstraction on top of the Record Attribute
258 infrastructure to allow the aggregation of multiple, cross-Attribute values
259 under a single search filter value, accessible through new, dynamic filters.
260
261 Each QueryParser filter will be created by the addition of a Composite Record
262 Attribute Definition. For instance, one may wish to create a Composite Record
263 Attribute Definition for an abstract "Item Type" interface component that
264 uses information from the item_type, vr_format, bib_level and item_form
265 Record Attribute Definitions, with each Composite Record Attribute Value
266 having a different combination of Record Attribute Values from some or all of
267 these Record Attribute Definitions. In this way, as single interface
268 component might be presented as a dropdown with options such as "All Books",
269 "All video recordings", "DVDs", "VHS Tapes", "E-Books", "Audio Books" and
270 "Large Print Books". Of particular note are the "DVDs" and "VHS Tapes"
271 entries, which include information from Record Attribute Definitions
272 completely separate from the others. Additionally, the Composite Record
273 Attribute Values defined by this Composite Record Attribute Definition
274 can be used to drive behavioral logic, such as alternate icon display or
275 link generation, in upgrade-friendly template adjustments.
276
277 Included in this development is a replacement for the single-attribute
278 Format filter supplied for basic search.  Instead, a Composite Attribute
279 is used to combine the values from Item Type, Item Form and Videorecording
280 Format in various ways that provide a more patron-friendly set of choices.
281
282 This new Format filter can be adjusted, or even replaced with a completely
283 local one, through configuration and without template adjustment.
284
285
286 Located URI visibility options
287 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
288 Before this, Evergreen restricted the visibility of bibliographic records
289 that make use of Located URIs in a way that attempts to model licensing
290 restrictions.
291
292 There now exists a global flag to allow sites the option of changing the
293 behaviour of Located URIs so that they act in a way analogous to copies
294 for visibility testing.  When the opac.located_uri.act_as_copy global flag
295 is enabled, Located URIs will cause their containing bib records to become
296 visible in searches where the URI is in scope to either ancestors of the
297 search library, as before, or descendents of the search library, as copies
298 do.  As before, if a preferred library is supplied by the user, it is
299 added to the list of visible org units to check.
300
301 Additionally, while the underlying UnAPI and supporting code was capable
302 of providing a reasonable and logical sort order for the Located URIs when
303 embedded as XML holdings elements, the client-facing UnAPI method was not
304 making use of that.  It now does, and uses the same sorting algorithm as
305 is used for copies.
306
307
308 Multi-valued Record Attributes and Controlled Record Attributes
309 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
310 Having identified common use cases and reasonable restrictions that can be
311 placed on the feature set, we have extended the Record Attribute
312 infrastructure to support both the extraction and storage of all instances
313 of a defined Attribute found within a bibliographic record, as well as
314 provide new and more powerful indexing of existing data, in several ways.
315
316 Record Attributes can now be defined by configuration as either single-valued
317 or multi-valued. For any Attribute configured as single-valued, only the
318 first value extracted from a record will be stored. This configuration
319 parameter and restriction is in place to support potential query
320 optimizations based on foreknowledge of whether a given Attribute is multi-
321 valued or not.
322
323 Record Attributes will be defined by configuration as either controlled or
324 uncontrolled. A controlled Record Attribute is one that has entries in the
325 Coded Value Map infrastructure specifying the valid values the record may
326 carry for this attribute. If defined as a controlled Attribute, any unknown
327 values extracted from a record will be ignored. Uncontrolled Attributes,
328 however, may contain any value. This configuration parameter and restriction
329 also supports potential query optimization.
330
331 We store uncontrolled attribute values in a new table with a monotonically
332 decreasing ID sequence, separating it from controlled values, reducing storage
333 requirements by retaining only unique values, and making lookup faster.
334
335 Restrictions
336 ++++++++++++
337  * A Record Attribute's values must match Coded Value Map entries if it is to be a Controlled Attribute. Coded Value Map control is indicated by a new "controlled" boolean on the config.record_attr_definition table.
338  * Record Attributes must "opt in" to multi-valued-ness. Record Attributes will opt in via a new "multi" boolean on config.record_attr_definition; this restriction enforces site config requirements by being explicit about the definition of "multi" fields.
339  * If controlled but not opt'd in to multi-mode, only the first value will be recorded but the new search mechanism will be used.
340  * Only single-valued Record Attributes will be available for use by the system as Sort Axes.
341  * Only controlled Record Attributes will be available for use by the TPAC as dynamically generated filter UI components, such as filter dropdowns or multi-selects.
342
343 New External Dependency
344 +++++++++++++++++++++++
345 This new feature requires the addition of the intarray extension to Postgres.
346 This is a stock extension available on most linux distributions via the same
347 package as the already-required plperl extension.
348
349
350 Restore OpenSearch Support
351 ^^^^^^^^^^^^^^^^^^^^^^^^^^
352 Restore previously held functionality from JSPAC to support OpenSearch in TPAC. 
353 This allows users to easily add the Evergreen search engine to their browser's 
354 built-in set of search engines.
355
356
357 Accepting payments with Stripe
358 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
359 Stripe is a payment processing service that lets
360 sites take credit card payments without payment card information ever
361 touching the sites' own servers.
362
363 NOTE: Using Stripe as a payment processor means that clients *must*
364 have Javascript enabled in order to submit fine payments through your
365 OPAC.
366
367 Library Settings
368 ++++++++++++++++
369 The following settings need to be set at the appropriate org level for
370 sites wanting to use Stripe.
371
372  * "Allow Credit Card Payments" (should be 'true')
373
374    credit.payments.allow
375
376  * "Enable Stripe payments" (should be 'true')
377
378    credit.processor.stripe.enabled
379
380  * "Stripe publishable key" (value provided by Stripe)
381
382    credit.processor.stripe.pubkey
383
384  * "Stripe secret key" (value provided by Stripe)
385
386    credit.processor.stripe.secretkey
387
388  * "Name default credit processor" (should be 'Stripe')
389
390    credit.processor.default
391
392
393 TPAC library pages
394 ^^^^^^^^^^^^^^^^^^
395 This feature adds one web page per library in the system to the TPAC at
396 http://hostname/eg/opac/library/<SHORTNAME> and
397 http://hostname/eg/opac/library/<ID>. The pages publish the following
398 information from Evergreen (if available):
399
400 * Name of the library
401 * Link to the lbrary web site (from `Library Information URL` library setting)
402 * Opening hours
403 * Email address
404 * Phone number
405 * Mailing address
406 * Link to parent library (if applicable)
407
408 Library pages are linked from the copy table on the record details page.
409
410 Structured data
411 +++++++++++++++
412 The library web pages publish schema.org structured data, which can enable
413 search engines and other systems to better understand your libraries and their
414 resources.
415
416
417 TPAC Metarecord Search and Holds
418 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
419 This feature adds support for searching and placing holds against 
420 metarecords.
421
422 Metarecord Searching
423 ++++++++++++++++++++
424 In the top search bar and in the advanced search page, there is a new
425 search modifier labeled "Group Formats and Editions".  When selected,
426 searches are performed against metarecords and metarecords are shown
427 in the results list.
428
429 For each metarecord, format icons for all constituent records are shown.
430 When a use clicks on a metarecord, if the metarecord has multiple
431 constituent records, the user is taken to the constituent records
432 list.  Similarly, when a metarecord only has one constituent record,
433 the user is directed to the record detail page for the constituent
434 record.
435
436 Metarecord Holds
437 ++++++++++++++++
438 Clicking the place hold link from the metarecord results page shows
439 the available formats and languages for the metarecord, allowing
440 the user to limit the scope of the hold.  Non-metarecord holds now
441 get a new "Advanced Holds Options" link which allows user to promote
442 a title hold to a metarecord hold, thus providing access 
443 to the formats / editions selector, before the hold is placed.
444
445 In the My Account holds list, icons for all selected formats are 
446 displayed in the Format columns for the hold.  When editing a 
447 metarecord hold, users may modify the desired formats and languages.
448
449 Configuration
450 +++++++++++++
451 Admins may disable this feature by un-commenting the "metarecord.disabled"
452 attribute in config.tt2
453
454
455 Web Content Accessibility Guidelines (WCAG) Compliance
456 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
457 To make the catalog more accessible to users with a range of disabilities,
458 including blindness and low vision, the catalog has been revised to better
459 comply with the Web Content Accessibility Guidelines (WCAG) 2.0. These
460 revisions target level "AA" of compliance.
461
462 For more information on WCAG, see http://www.w3.org/WAI/intro/wcag