From e4cbe67a9bd8788f8e750c8ca298489e05749cd2 Mon Sep 17 00:00:00 2001 From: Mike Rylander Date: Thu, 23 Jan 2014 10:40:16 -0500 Subject: [PATCH] Release notes Signed-off-by: Mike Rylander Signed-off-by: Jeff Godin --- .../OPAC/Located_URI_visibility.txt | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 docs/RELEASE_NOTES_NEXT/OPAC/Located_URI_visibility.txt diff --git a/docs/RELEASE_NOTES_NEXT/OPAC/Located_URI_visibility.txt b/docs/RELEASE_NOTES_NEXT/OPAC/Located_URI_visibility.txt new file mode 100644 index 0000000000..4ef9b0e1b7 --- /dev/null +++ b/docs/RELEASE_NOTES_NEXT/OPAC/Located_URI_visibility.txt @@ -0,0 +1,21 @@ +Located URI visibility options +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 descendents 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. + -- 2.43.2