Upgrade notes\r
~~~~~~~~~~~~~\r
\r
-Located URI search scope\r
-^^^^^^^^^^^^^^^^^^^^^^^^\r
-Recognizing that electronic resources are often licensed for an entire library\r
-system rather than just a single library, the search scope for located URIs has\r
-changed to match from the highest point in the hierarchy down, rather than from\r
-the bottom up. In previous releases of Evergreen, if you had a MARC record with\r
-a URI located at 'BR1', a search for that record at the 'SYS1' scope would\r
-include the record in its results. The current release of Evergreen would not\r
-include the record in its results; the scope needs to be set at the level of\r
-'BR1' in the hierarchy or below.\r
-\r
-Therefore, you may want to run a SQL statement like the following, edited to\r
-match the short names of your branches and systems, to change the located\r
-URIs so that searches at the system level continue to return results for\r
-located URIs:\r
-\r
-------------------------------------------------------------------------------\r
-UPDATE biblio.record_entry\r
- SET marc = replace(\r
- replace(\r
- marc, \r
- '<subfield code="9">BR1</subfield>',\r
- '<subfield code="9">SYS1</subfield>'\r
- ),\r
- '<subfield code="9">BR3</subfield>',\r
- '<subfield code="9">SYS2</subfield>'\r
- ) WHERE marc LIKE '<subfield code="9">BR1</subfield>'\r
- OR marc LIKE '<subfield code="9">BR3</subfield>'\r
-;\r
-------------------------------------------------------------------------------\r
+Z39.50 server definitions\r
+^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
+Z39.50 server target definitions have been removed from the sample\r
+`opensrf.xml.example` file. To migrate existing settings from your\r
+`opensrf.xml` configuration file to the database, peform the\r
+following steps:\r
+\r
+. First, set up your custom Z39.50 sources in the database. For\r
+ each entry in `z3950/services`, map the following XML paths to the\r
+ corresponding `config.z3950_source` table column as follows:\r
++\r
+ ** `z3950/services/<entry>` = name\r
+ ** `//<entry>/name` = label\r
+ ** `//<entry>/host` = host\r
+ ** `//<entry>/port` = port\r
+ ** `//<entry>/db` = db\r
+ ** `//<entry>/record_format` = record_format\r
+ ** `//<entry>/transmission_format` = transmission_format\r
++\r
+. Then, for each attribute defined in the `<attrs>` element for\r
+ a given service, map the following XML paths to the corresponding\r
+ `config.z3950_attr` table column as follows:\r
++\r
+ ** `z3950/services/<entry>` = source\r
+ ** `//<entry>/attrs/<attr>` = name\r
+ ** `//<entry>/attrs/<attr>/code` = code\r
+ ** `//<entry>/attrs/<attr>/format` = format\r
++\r
+. After adding the new Z39.50 sources and corresponding attributes, you will need to log out of the staff client and log back into the\r
+staff client to retrieve the new entry values. If a given Z39.50 server does not work for a given attribute, pay attention to the\r
+`truncation` column for the attribute.\r
\r
New features\r
~~~~~~~~~~~~\r
\r
+*OPAC*\r
+\r
+Copy Location Groups\r
+^^^^^^^^^^^^^^^^^^^^\r
+This feature allows staff to create and name sets of copy locations to use as\r
+a search filter in the catalog. OPAC-visible groups will display within the\r
+library selector in the template toolkit OPAC. When a user selects a group\r
+and performs a search, the set of results will be limited to records that have\r
+copies in one of the copy locations within the group. Groups can live at any\r
+level of the library hierarchy and may include copy locations from any parent \r
+org unit or child org unit.\r
+\r
+For advanced users, this change includes a new Query Parser filter called\r
+location_groups().\r
+\r
*Cataloging*\r
\r
-*Prevent bibliographic records from having attached copies*\r
+Prevent bibliographic records from having attached copies\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
\r
To enable libraries to designate specific sets of records as only for use\r
as electronic resources, it is possible to configure a bibliographic source\r
a cataloger from adding volumes or MFHD records to records belonging to that\r
source.\r
\r
-*Switch copy location name and library short name in copy editor*\r
+Switch copy location name and library short name in copy editor\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
\r
By default, the copy editor shows the library shortname ('BR1' or 'CONS')\r
followed by the copy location name ('Stacks', 'Reference'). A new workstation\r
locations at the consortial level and want to enable quick keyboard navigation\r
to copy locations by typing just the first letters of the copy location.\r
\r
+Authentication proxy\r
+~~~~~~~~~~~~~~~~~~~\r
+To support integration of Evergreen with organizational authentication systems,\r
+and to reduce the proliferation of user names and passwords, Evergreen offers \r
+a new service called `open-ils.auth_proxy`. If you enable the service,\r
+`open-ils.auth_proxy` supports different authentication mechanisms\r
+that implement the `authenticate` method. You can define a chain of these\r
+authentication mechanisms to be tried in order within the `<authenticators>`\r
+element of the `opensrf.xml` configuration file, with the option of falling\r
+back to the `native` mode that uses Evergreen's internal method of password\r
+authentication.\r
+\r
+This service only provides authentication; there is no support for automatic\r
+provisioning of accounts. To authenticate against any authentication system,\r
+the user account must first be defined within the Evergreen system, and\r
+authentication will be based on the user name as it exists in Evergreen.\r
+\r
+A sample authentication mechanism for LDAP is provided in\r
+`Open-ILS::Application::AuthProxy::LDAP_AUTH`, and corresponding sample\r
+attributes can be found in `opensrf.xml.example`.\r
+\r
+\r
*Reports*\r
\r
\r
-*New views for reporting sources*\r
+New views for reporting sources\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
\r
To support the creation of collection development reports, the following\r
reporting sources have been added:\r