Records with located URIs are retrieved in Copy Location and Copy Location Group searches

Bug #1745233 reported by Michele Morgan
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.1
Fix Released
High
Unassigned

Bug Description

Evergreen 3.0

Records with located uris at the CONS level are retrieved in searches in all Copy Location Groups.

Additionally, when a Copy Location Group is owned by the same org unit (or parent) as a located URI, the record with that located uri will be retrieved in searches limited to that Copy Location Group.

This is occurring in both the public opac and staff client.

To reproduce on a concerto system:

- Create a copy location group called "My BR1 Group" owned by BR1. It's not necessary to add any copy locations to the group.
- Perform a search on "tolkien" - the stock Tolkien records with located uris at the CONS level will be retrieved

Next:

- Create a record with title "My BR1 URI" with a located URI for BR1
- Create a second Copy Location Group called "My BR3 Group" owned by BR3
- Perform a search for "My BR1 URI" in location group "My BR1 Group" - the record is retrieved.
- Perform the search for "My BR1 URI" in location group "My BR3 Group" - the record is not retrieved.

Records with only uris should not be retrieved in any searches that are limited to Copy Location Groups.

Revision history for this message
Michele Morgan (mmorgan) wrote :

Adding a note that located uris are also retrieved in searches limited to individual Copy Locations belonging to the same org unit from the Advanced Search page.

Kathy Lussier (klussier)
tags: added: opacvisibility
Kathy Lussier (klussier)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kathy Lussier (klussier) wrote :

This bug is critical for the MassLNC consortia.

As I mentioned in https://bugs.launchpad.net/evergreen/+bug/1730758/comments/9, we delayed a 3.0 upgrade due to the search visibility bugs in 3.0. There has been significant improvement in search with the patches for bug 1743650, bug 1730758, and bug 1736419.

This bug is the one remaining showstopper for this 3.0 upgrade. Our consortia make heavy use of copy location groups to help narrow down titles in the children's collection or the adult collection. With this bug, a user searching for materials on kings in the children's copy location group would easily retrieve Stephen King e-titles. There are many other adult electronic titles we don't want to be retrieved with a search scoped to children's collections and juvenile electronic titles we don't want to be retrieved with a search scoped to our adult collections.

Michele Morgan (mmorgan)
summary: - Records with located URIs are retrieved in Copy Location Group searches
+ Records with located URIs are retrieved in Copy Location and Copy
+ Location Group searches
Revision history for this message
Mike Rylander (mrylander) wrote :

I've pushed a branch for testing that skips Located URI testing when a shelving location or location group filter is used in a search.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1745233-luri-vs-copy-loc-search

tags: added: pullrequest
Revision history for this message
Cesar V (cesardv) wrote :
Andrea Neiman (aneiman)
tags: added: signedoff
Changed in evergreen:
milestone: none → 3.0.8
Revision history for this message
Kathy Lussier (klussier) wrote :

It works in our testing too! I've added a signoff and merged it to master, release 3.1 and release 3.0.

Thank you Mike and Cesar!

Changed in evergreen:
status: Confirmed → Fix Committed
Kathy Lussier (klussier)
tags: added: searchvisibility
removed: opacvisibility
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.