--- /dev/null
+KCLS Evergreen 2.6 + 2.7 Combined Release Notes
+===============================================
+:toc:
+:numbered:
+:toclevels: 3
+
+KCLS Special Considerations
+---------------------------
+
+Local Support
+~~~~~~~~~~~~~
+
+Some features require additional development to make them work for
+KCLS, typically because they modify templates for which we maintain
+local versions. In those cases, you'll see a note along the top
+of each feature that looks something like:
+
+NOTE: Requires local template modifications.
+
+For such features, we should decide if we want to include them and
+what the priority for including them might be.
+
+Catalog Changes
+~~~~~~~~~~~~~~~
+
+Any features that modify behavior in the catalog (TPAC) will only affect
+the staff view of the catalog. None of these changes will affect
+Bibliocommons.
+
+New Features
+------------
+
+
+Cataloging
+~~~~~~~~~~
+
+Enhancements to Evergreen's MARC Editor Concerning Fixed Fields
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This work is a combination of two features. One provides suggested
+values in a right-click context menus for fixed field values based on
+the 'type' of the record being edited. The other provides a wizard to
+help specifically with the Physical Characteristics of the record, i.e.
+the 007 field.
+
+Right-Click Context Menus
++++++++++++++++++++++++++
+Users will be able to right-click on the value control for fixed fields
+in the MARC Editor, and Evergreen will provide a menu from which the
+user can select a possible value. This will work for fixed fields where
+Evergreen already contains information from the Library of Congress's
+MARC 21 standard.
+
+Example:
+
+image::media/ffer-right-click.png["Right-clicking the BLvl field"]
+
+Evergreen already comes loaded with information from the Library of
+Congress's MARC 21 standard on possible values for some fixed fields.
+
+The following table shows which fixed fields for which 'Record Types'
+have values already loaded into Evergreen.
+
+---------------------------------------------------------
+
+ Fixed Field | Record Types
+-------------+-----------------------------------
+ Audn | {BKS,COM,REC,SCO,SER,VIS}
+ BLvl | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
+ Form | {BKS,MAP,MIX,REC,SCO,SER,VIS}
+ Lang | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
+ LitF | {BKS}
+ Type | {BKS,COM,MAP,MIX,REC,SCO,SER,VIS}
+
+
+---------------------------------------------------------
+
+A 'Record Type' is itself a combination of the 'Type of Record' (fixed
+field name: Type) and 'Bibliographic Level' (fixed field name: BLvl)
+elements of the MARC leader (positions 06 and 07 respectively). You can
+see a record's Record Type in the MARC Editor as shown in
+this screenshot:
+
+'Record Type':
+
+image::media/ffer-record-type.png["This Record Type is REC"]
+
+A user may add values to these fixed fields as well as to other fixed
+fields through the MARC Coded Value Maps interface found under the Admin
+-> Server Administration menu in the staff client. These are grouped by
+Record Attribute Types (a superset of fixed fields) which have labels
+such as 'Alph', 'Biog', 'Videorecording format', and 'Language'.
+
+From LOC Fixed Fields documentation, 'Alph' is 'Original alphabet or
+script of title', 'Biog' is 'Biography', 'Videorecording format' is from
+the 007 field, 'Language' is positions 35-37 of the 008, and so on.
+Other Record Attribute Types such as 'Author' are, of course, not fixed
+fields at all.
+
+When users add new values here, the right-click context menus of the
+fixed fields in the MARC Editor will include those values.
+
+All values added for any fixed field in the Coded Value Map will display
+for any 'Record Type' that uses that fixed field.
+
+Users of the MARC Editor always retain the option of leaving a fixed
+field blank, entering the special values # or |, or entering a value not
+provided by the right-click context menu.
+
+Physical Characteristics Wizard
++++++++++++++++++++++++++++++++
+By right-clicking on an existing or new 007 field in the MARC Editor, users
+will be able to enter a wizard that leads them step-by-step through the
+positions in that 007 field, telling them the significance of the current
+position and providing a drop-down list of possible values.
+
+Launching the Physical Characteristics Wizard:
+
+image::media/ffer-open-wizard.png["Launching the Physical Characteristics Wizard"]
+
+Choosing the Category of Material:
+
+image::media/ffer-007-00.png["Choosing the Category of Material"]
+
+Choosing a value for a later position:
+
+image::media/ffer-007-smd.png["Choosing a value for a later position"]
+
+
+marc_export script replacement
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The `/openils/bin/marc_export` script is completely rewritten. This
+new version accepts all of the same command line options as the old
+version as well as some new options.
+
+The rewritten `marc_export` talks directly to your Evergreen database
+and is a great deal faster than the previous version. Because the new
+script talks directly to the database, it needs to know how to
+connect. To facilitate this, a new option, `--store`, was added that
+allows the user to specify one of three Evergreen storage backends to
+use when exporting records. The valid choices are `reporter`,
+`cstore`, or `storage`. The default of `reporter` should work in most
+cases, but if you do have a separate reporter database and you know
+you want to talk directly to your main production database, then you
+will probably want to choose either `cstore` or `storage`.
+
+In addition to the `--store` option, a `--since` option is also added
+so that you can specify output of an update file of records changed,
+added, and/or deleted since the given date. The `--since` option uses
+a fairly flexible date parser and can accept a wide range of date
+formats including ISO 8601, man common date formats such as M/D/Y
+(common in the US) or D/Mon/Y (with the first 3 characters or more of
+the month spelled out), as well as several less common date formats.
+Special date strings such as `yesterday`, `today`, `yesterday week`,
+and `today week` are also supported. For more information see the
+VALID DATE FORMATS section of the `Date::Manip::Date` man page.
+Available online here:
+
+http://search.cpan.org/~sbeck/Date-Manip-6.42/lib/Date/Manip/Date.pod#VALID_DATE_FORMATS
+
+There is one final difference between the new script and the old
+`marc_export`. The new script does not output progress as it
+executes. Many of the statistics that the script reported are not
+readily available to the new script. It was deemed better to just not
+output any progress rather than to output something different from the
+old program. If your scripts parse the output from `marc_export`,
+they will need to modified not to expect any.
+
+TPAC Copy View/Edit Links
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+Adds 'view' and 'edit' links next to each copy in the TPAC record
+details copy grid when viewed from within the staff client. The 'edit'
+link only appears when the authenticated user has permission to edit the
+specified copy.
+
+Both links open new tabs. When the 'edit' link is used, the 'Unified
+Volume/Item Creator/Editor' org unit setting is inspected to determine
+which style of copy edit interface to display. When the 'view' link is used,
+the copy details display in the Item Status screen.
+
+
+
+
+Display "Imported As" in Vandelay Queue
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This simple new feature appears within the Cataloging *MARC Batch
+Import/Export* screens. When viewing the contents of a Vandelay queue,
+for example when inspecting a queue or right after bib imports, there is
+a new column called _Imported As_. This new column displays the
+record ID, also known as the bib number, of the bib records currently
+listed in the queue. If the bib records listed in the queue have not been
+imported yet, this column is blank until the queued records are imported.
+After import the queued records will display the assigned record ID for
+the listed bib(s).
+
+
+
+
+MARC Stream Importer
+^^^^^^^^^^^^^^^^^^^^
+
+NOTE: We are already using this. (We developed it).
+
+New command line options were added to marc_stream_importer.pl for
+passing additional Vandelay import flags. Prior to this change, only
+auto-overlay-exact was supported.
+
+New options:
+
+ * --auto-overlay-exact
+ ** Overlay/merge on exact 901c matches
+ * --auto-overlay-1match
+ ** Overlay/merge when exactly one match is found
+ * --auto-overlay-best-match
+ ** Overlay/merge on best match
+ * --import-no-match
+ ** Import when no match is found
+
+Like Vandelay, these options can be combined.
+
+
+
+
+Monograph Part Merging
+^^^^^^^^^^^^^^^^^^^^^^
+
+The monograph part list for a bibliographic record may, over time, diverge from
+the proscribed format, resulting in multiple labels for what are essentially the
+same item. For instance, ++Vol.{nbsp}1++ may have variants
+like ++V.1++, ++Vol{nbsp}1++, or ++{nbsp}Vol.{nbsp}1++ (leading
+space).This feature will allow cataloging staff to collapse the variants into
+one value.
+
+
+Circulation
+~~~~~~~~~~~
+
+Lost Item Billing: New Min/Max Price Settings
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When an item is marked lost, the user is typically billed for the item.
+In Evergreen, they can either be charged the amount recorded in the item
+object, or if that value is blank (or zero), charged a default price
+(controlled by settings).
+
+In addition to these existing settings, now we can accommodate a range of
+prices by saying the patron should be billed at least 'X' and not more
+than 'Y'. This also allows you to effectively set a fixed price for all
+lost items by setting min and max to the same amount.
+
+New Org Unit Settings
++++++++++++++++++++++
+ * Minimum Item Price: circ.min_item_price
+ * Maximum Item Price: circ.max_item_price
+
+New Permissions
++++++++++++++++
+ * UPDATE_ORG_UNIT_SETTING.circ.min_item_price
+ * UPDATE_ORG_UNIT_SETTING.circ.max_item_price
+
+
+User Editor: "Update Expire Date" button
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+A new button labeled "Update Expire Date" is added in the user
+editor next to expire date field. This button can be used to
+re-calculate the user's expire date based on the current profile's
+permission interval and today's date.
+
+This is similar to how the expire date is populated when creating a
+new user, or when changing the profile group.
+
+This button simplifies the process of "renewing" a user, by
+eliminating the requirement that staff manually enter a new expire
+date.
+
+A button is used here so that the updating of the expire date
+remains an intentional process, not one that happens upon any edit.
+
+Change to Holds Shelf Expire Report
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: We are already using this.
+
+When limiting to Clearable Holds in the Browse Holds Shelf interface, the
+system will no longer display and clear holds expiring today. Instead, it will
+look for holds that expired before today.
+
+Support holds targeting and fulfillment of precats for ILL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Adds support for holds targeting and fulfillment of copy-level holds on
+pre-cat records. This feature makes integration with FulfILLment, NCIP and
+other ILL mediators easier because pre-cat copies can successfully be used for
+the ILL records.
+
+
+Support for a Lost and Paid Status
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This feature supports a new, optional, _Lost and Paid_ status that can be used
+by sites that want to distinguish between lost items with outstanding bills and
+those that have been fully paid. A site may want to make this distinction to
+set different OPAC visibility or holdability rules for these items.
+
+If enabled, when a lost item is fully paid, the copy's status will automatically
+change to _Lost and Paid_.
+
+New setting available via the Library Settings Editor
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+- Use Lost and Paid copy status (circ.use_lost_paid_copy_status)
+
+OPAC
+~~~~
+
+Composite Record Attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+With this feature we create an abstraction on top of the Record Attribute
+infrastructure to allow the aggregation of multiple, cross-Attribute values
+under a single search filter value, accessible through new, dynamic filters.
+
+Each QueryParser filter will be created by the addition of a Composite Record
+Attribute Definition. For instance, one may wish to create a Composite Record
+Attribute Definition for an abstract "Item Type" interface component that
+uses information from the item_type, vr_format, bib_level and item_form
+Record Attribute Definitions, with each Composite Record Attribute Value
+having a different combination of Record Attribute Values from some or all of
+these Record Attribute Definitions. In this way, as single interface
+component might be presented as a dropdown with options such as "All Books",
+"All video recordings", "DVDs", "VHS Tapes", "E-Books", "Audio Books" and
+"Large Print Books". Of particular note are the "DVDs" and "VHS Tapes"
+entries, which include information from Record Attribute Definitions
+completely separate from the others. Additionally, the Composite Record
+Attribute Values defined by this Composite Record Attribute Definition
+can be used to drive behavioral logic, such as alternate icon display or
+link generation, in upgrade-friendly template adjustments.
+
+Included in this development is a replacement for the single-attribute
+Format filter supplied for basic search. Instead, a Composite Attribute
+is used to combine the values from Item Type, Item Form and Videorecording
+Format in various ways that provide a more patron-friendly set of choices.
+
+This new Format filter can be adjusted, or even replaced with a completely
+local one, through configuration and without template adjustment.
+
+
+
+Located URI visibility options
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications. We are not currently
+using URI's.
+
+Before this, Evergreen restricted the visibility of bibliographic records
+that make use of Located URIs in a way that attempts to model licensing
+restrictions.
+
+There now exists a global flag to allow sites the option of changing the
+behaviour of Located URIs so that they act in a way analogous to copies
+for visibility testing. When the opac.located_uri.act_as_copy global flag
+is enabled, Located URIs will cause their containing bib records to become
+visible in searches where the URI is in scope to either ancestors of the
+search library, as before, or descendants of the search library, as copies
+do. As before, if a preferred library is supplied by the user, it is
+added to the list of visible org units to check.
+
+Additionally, while the underlying UnAPI and supporting code was capable
+of providing a reasonable and logical sort order for the Located URIs when
+embedded as XML holdings elements, the client-facing UnAPI method was not
+making use of that. It now does, and uses the same sorting algorithm as
+is used for copies.
+
+
+Multi-valued Record Attributes and Controlled Record Attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+Having identified common use cases and reasonable restrictions that can be
+placed on the feature set, we have extended the Record Attribute
+infrastructure to support both the extraction and storage of all instances
+of a defined Attribute found within a bibliographic record, as well as
+provide new and more powerful indexing of existing data, in several ways.
+
+Record Attributes can now be defined by configuration as either single-valued
+or multi-valued. For any Attribute configured as single-valued, only the
+first value extracted from a record will be stored. This configuration
+parameter and restriction is in place to support potential query
+optimizations based on foreknowledge of whether a given Attribute is multi-
+valued or not.
+
+Record Attributes will be defined by configuration as either controlled or
+uncontrolled. A controlled Record Attribute is one that has entries in the
+Coded Value Map infrastructure specifying the valid values the record may
+carry for this attribute. If defined as a controlled Attribute, any unknown
+values extracted from a record will be ignored. Uncontrolled Attributes,
+however, may contain any value. This configuration parameter and restriction
+also supports potential query optimization.
+
+We store uncontrolled attribute values in a new table with a monotonically
+decreasing ID sequence, separating it from controlled values, reducing storage
+requirements by retaining only unique values, and making lookup faster.
+
+Restrictions
+++++++++++++
+ * 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.
+ * 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.
+ * 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.
+ * Only single-valued Record Attributes will be available for use by the system as Sort Axes.
+ * 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.
+
+
+Restore OpenSearch Support
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+Restore previously held functionality from JSPAC to support OpenSearch in TPAC.
+This allows users to easily add the Evergreen search engine to their browser's
+built-in set of search engines.
+
+
+Accepting payments with Stripe
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+Stripe is a payment processing service that lets
+sites take credit card payments without payment card information ever
+touching the sites' own servers.
+
+NOTE: Using Stripe as a payment processor means that clients *must*
+have Javascript enabled in order to submit fine payments through your
+OPAC.
+
+Library Settings
+++++++++++++++++
+The following settings need to be set at the appropriate org level for
+sites wanting to use Stripe.
+
+ * "Allow Credit Card Payments" (should be 'true')
+
+ credit.payments.allow
+
+ * "Enable Stripe payments" (should be 'true')
+
+ credit.processor.stripe.enabled
+
+ * "Stripe publishable key" (value provided by Stripe)
+
+ credit.processor.stripe.pubkey
+
+ * "Stripe secret key" (value provided by Stripe)
+
+ credit.processor.stripe.secretkey
+
+ * "Name default credit processor" (should be 'Stripe')
+
+ credit.processor.default
+
+
+TPAC library pages
+^^^^^^^^^^^^^^^^^^
+
+NOTE: We already have this in our local TPAC.
+
+This feature adds one web page per library in the system to the TPAC at
+`http://hostname/eg/opac/library/<SHORTNAME>` and
+`http://hostname/eg/opac/library/<ID>`. The pages publish the following
+information from Evergreen (if available):
+
+* Name of the library
+* Link to the library web site (from `Library Information URL` library setting)
+* Opening hours
+* Email address
+* Phone number
+* Mailing address
+* Link to parent library (if applicable)
+
+Library pages are linked from the copy table on the record details page.
+
+Structured data
++++++++++++++++
+The library web pages publish schema.org structured data, which can enable
+search engines and other systems to better understand your libraries and their
+resources.
+
+
+TPAC Metarecord Search and Holds
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+This feature adds support for searching and placing holds against
+metarecords.
+
+Metarecord Searching
+++++++++++++++++++++
+In the top search bar and in the advanced search page, there is a new
+search modifier labeled "Group Formats and Editions". When selected,
+searches are performed against metarecords and metarecords are shown
+in the results list.
+
+For each metarecord, format icons for all constituent records are shown.
+When a use clicks on a metarecord, if the metarecord has multiple
+constituent records, the user is taken to the constituent records
+list. Similarly, when a metarecord only has one constituent record,
+the user is directed to the record detail page for the constituent
+record.
+
+Metarecord Holds
+++++++++++++++++
+Clicking the place hold link from the metarecord results page shows
+the available formats and languages for the metarecord, allowing
+the user to limit the scope of the hold. Non-metarecord holds now
+get a new "Advanced Holds Options" link which allows user to promote
+a title hold to a metarecord hold, thus providing access
+to the formats / editions selector, before the hold is placed.
+
+In the My Account holds list, icons for all selected formats are
+displayed in the Format columns for the hold. When editing a
+metarecord hold, users may modify the desired formats and languages.
+
+Configuration
++++++++++++++
+Admins may disable this feature by un-commenting the "metarecord.disabled"
+attribute in config.tt2
+
+
+Web Content Accessibility Guidelines (WCAG) Compliance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+Some of these issues have likely been addressed in our own templates
+(e.g. improving colors for colorblindness), but others likely have
+not (screen reader improvements).
+
+To make the catalog more accessible to users with a range of disabilities,
+including blindness and low vision, the catalog has been revised to better
+comply with the Web Content Accessibility Guidelines (WCAG) 2.0. These
+revisions target level "AA" of compliance.
+
+For more information on WCAG, see http://www.w3.org/WAI/intro/wcag
+
+Added Content by Record ID
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Template Toolkit OPAC will now load all Added Content by the Record ID, not
+just jacket images. This will allow added content providers that support it to
+load additional content by other identifiers.
+
+
+
+
+Content Cafe Added Content Update
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The OpenILS::WWW::AddedContent::ContentCafe provider has been updated to use the
+newer Content Cafe 2 API in full. With this update the ability to load content
+based on ISBN or UPC is now enabled.
+
+
+"No Image" Images
++++++++++++++++++
+With the updated code the option for displaying a "No Image" image or a 1x1
+pixel image is no longer available. Instead the Apache-level "blank image" rules
+will trigger when no image is available. The configuration option controlling
+this behavior can thus be removed from opensrf.xml entirely.
+
+
+Identifier Selection
+++++++++++++++++++++
+By default the module will prefer ISBNs over UPCs, but will request information
+for both. If you wish for UPCs to be preferred, or wish one of the two
+identifier types to not be considered at all, you can change the
+"identifier_order" option in opensrf.xml. When the option is present only the
+identifier(s) listed will be sent.
+
+
+More RDA 264 tag support
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+The OPAC now displays RDA bib tag 264 information for Producer, Distributor,
+Manufacturer, and Copyright within a full bib record’s summary. This is in
+addition to the RDA bib tag 264 publisher information, indicator 2 equal
+to 1, that was already being displayed in previous versions of Evergreen.
+The OPAC full bib view also now contains the Schema.org copyrightYear value.
+
+Additionally, this information is now available in search results as well
+when viewing more details.
+
+
+Sitemap generator
+^^^^^^^^^^^^^^^^^
+
+NOTE: We already have this. (kcls-2.5.003)
+
+A http://www.sitemaps.org[sitemap] directs search engines to the pages of
+interest in a web site so that the search engines can intelligently crawl
+your site. In the case of Evergreen, the primary pages of interest are the
+bibliographic record detail pages.
+
+The sitemap generator script creates sitemaps that adhere to the
+http://sitemaps.org specification, including:
+
+* limiting the number of URLs per sitemap file to no more than 50,000 URLs;
+* providing the date that the bibliographic record was last edited, so
+ that once a search engine has crawled all of your sites' record detail pages,
+ it only has to reindex those pages that are new or have changed since the last
+ crawl;
+* generating a sitemap index file that points to each of the sitemap files.
+
+
+
+Acquisitions
+~~~~~~~~~~~~
+
+Acquisitions speed improvements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Improvements to the rendering of the acquisitions fund selector will improve
+the speed at which the purchase order, copy grid, PO/invoice charge creator,
+and distribution formula editor load. These speed improvements will be most
+noticeable for sites that use many funds.
+
+
+Differentiate Delayed vs. Canceled Items
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Background
+++++++++++
+
+Canceled and delayed lineitems and copies in acquisitions are marked as
+canceled in the database. The determining factor of whether an item is
+delayed or canceled is the keep_debits flag on the cancel reason.
+
+The changes below help to differentiate between these two closely-related
+states by improving labels in the interface and providing separate counts
+for delayed vs. canceled.
+
+Changes
++++++++
+
+ * Show number canceled and number delayed in lineitem summary displays
+ ** Includes summary displays in invoices and copy grids
+ * Update stock cancel cause labels to include "Canceled:.." and
+ "Delayed:..." prefixes.
+ * When a lineitem or copy is marked as canceled, show the cancel cause
+ label in the interface instead of the bare (and misleading and non-I18N
+ friendly) string "cancelled".
+ ** Related, for non-canceled states, show a translatable string
+ representing the name of the state instead of the bare state code.
+ * Add cancel cause labels to the print PO and lineitem worksheet templates.
+
+Support Cancellation of Delayed Lineitems
++++++++++++++++++++++++++++++++++++++++++
+
+When a lineitem is marked as delayed (canceled with keep_debits == true),
+allow staff to cancel the lineitem again in the ACQ PO/Selection List interface.
+Once a lineitem is marked as truly canceled, it cannot be canceled again.
+
+Administration
+~~~~~~~~~~~~~~
+
+Add granular settings for requiring staff initials for notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+There are now three separate library settings for controlling whether staff
+are required to input their initials when creating different types of notes.
+See new library settings below.
+
+Any pre-existing library setting for requiring staff initials are preserved
+during the upgrade process. After upgrading, you may choose to change the set
+behavior for any of the three new settings.
+
+New Library Settings
++++++++++++++++++++++
+ * Require staff initials for entry/edit of patron standing penalties and messages. (ui.staff.require_initials.patron_standing_penalty)
+ * Require staff initials for entry/edit of patron notes. (ui.staff.require_initials.patron_info_notes)
+ * Require staff initials for entry/edit of copy notes. (ui.staff.require_initials.copy_notes)
+
+Switch to XLSX format for Excel report output
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+With previous versions of Evergreen, reports generated in the Excel output
+were limited to a maximum of 64,000 rows. This was a limitation due to the
+Excel format ".xls". Now, new report outputs for Excel will use format ".xlsx"
+which allows for much larger report output rows.
+
+Report Editing
+^^^^^^^^^^^^^^
+Users may now view and edit existing reports.
+
+With each report in the Reports folder view there are two new links,
+one for viewing (read-only) and one for editing. After changing a
+report, the user has the option to save the modified report
+or create a new report with the new values, in effect cloning
+the original report.
+
+When saving a changed report that has a pending run, the user
+will be warned of this and asked if they would prefer to modify the
+scheduled report or to instead save the changed values as a new
+report, leaving the original report intact.
+
+
+Reports Documentation Links and Hints
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ * Report templates support a new External URL field, which may
+ contain a link to template-specific, local documentation.
+
+ ** When set, a link to the external documentation will be
+ displayed in a new column in the template list and within
+ the report editor.
+
+ ** URL's are set in the 'Documentation URL' entry.
+
+ * Template display fields and filters support a new Field Hint
+ value. When set, hints are displayed in the report editor.
+
+ ** Values are set via the 'Change Field Hint' option along
+ the bottom of the template editor.
+
+
+Secondary Permission Groups
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+NOTE: Requires local template modifications.
+
+The patron registration/edit screen now has an interface for adding
+secondary permission groups (profiles) to a user account. This gives
+library staff the ability to assign sets of permissions from multiple
+permission groups to a single user. For example, if you have a
+cataloger who also does acquisitions, and you have separate permission
+groups for Catalogers and Acquisitions, the new UI allows you to add
+acquisitions as a secondary perm group on the cataloger's account, thus
+granting all Acquisitions permissions to that user without changing the
+user's primary profile group.
+
+Library staff require the *CREATE_USER_GROUP_LINK* and
+*REMOVE_USER_GROUP_LINK* permissions (which already exist in Evergreen) in order
+to add or remove a user's secondary permission groups.
+
+
+Set resource limits for Clark Kent
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Several parameters are now available for the reporter daemon process
+(`clark-kent.pl`) to control resource usage. These can be used to
+reduce the chances that a malformed report can cause indigestion
+on a database or reports server. The new parameters, which can be
+set in `opensrf.xml` or as command-line switches for `clark-kent.pl` are
+
+* `//reporter/setup/statement_timeout` / `--statement-timeout`
+
+Number of minutes to allow a report's underlying SQL query
+to run before it gets cancelled. Default value is
+60 minutes. If a report's query gets cancelled, the
+error_text value will be set to a valid that indicates that
+the allowed time was exceeded.
+
+* `//reporter/setup/max_rows_for_charts` / `--max-rows-for-charts`
+
+Number of rows permitted in the query's output before
+Clark Kent refuses to attempt to draw a graph. Default
+value is 1,000 rows.
+
+* `//reporter/setup/resultset_limit` / `--resultset-limit`
+
+If set, truncates the report's output to the specified
+number of hits. Note that it will not be apparent
+to a staff user if the report's output has been
+truncated. Default value is unlimited.
+
+The report concurrency (i.e., the number of reports that Clark
+Kent will run in parallel) can now also be controlled via
+the `opensrf.xml` setting `//reporter/setup/parallel`.
+
+Client
+~~~~~~
+
+Web client preview
+^^^^^^^^^^^^^^^^^^
+
+The 2.7 release will contain a preview of web client circulation features.
+Circulation is the first step in moving all staff functions from the existing
+XULRunner-based client to a web application that will be based on AngularJS.
+
+Evergreen is moving away from the existing client because XULRunner no longer
+supports features critical to the Evergreen software, including remote XUL,
+multi-part streaming, and XML JavaScript. The new web client is expected to
+show some speed improvements, to provide comprehensive support for
+internationalization/localization, to provide good support for assistive
+technologies, to be easier to customize locally, and to be more mobile friendly.
+
+The intent of the preview is to make it easier for end users at Evergreen sites
+to try the new client, become familiar with its features, and to
+discover/report bugs that are found. Instructions to implement the web client
+can be found in the code in Open-ILS/web/js/ui/default/staff/README.install.
+These will be revised and moved to the full README for 2.7.1.
+
projects / working / Evergreen.git / commitdiff