Records with Located URIs retrieved out of scope when org units are not OPAC visible

Bug #1743650 reported by Kathy Lussier
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Evergreen release 3.0

We're continuing to see record visibility issues in the public catalog on a production-data test system where records with Located URI are retrieved out of scope, even with the fixes from bug 1736419 and bug 1730758 applied. It appears to be an issue that occurs when org units are set to be OPAC invisible.

I confirmed the behavior on a Concerto test system by doing the following:

1. I added two test records to the system. The first has a located URI owned by BR1. The second has a located URI owed by BR2 and another located URI owned by SYS2
2. I set SYS1 to be OPAC invisible. Both records are retrieved out of scope.
3. When I reset SYS1 to be visible and set BR1 to be OPAC invisible, the record with a luri owned by BR2 and SYS2 is retrieved out of scope.
4. When I reset BR1 to be OPAC visible and set BR2 to be OPAC invisible, the record with a luri owned by BR1 is retrieved out of scope.

Adding an note that every time I just org unit visibility, I restarted autogen, OpenSRF services, and apache. These problems appear to be restricted to the public catalog. Searches from the staff client appear to be retrieving records as expected.

In our production systems, most of our system-level org units are not OPAC visible (we use the opac.org_unit.non_inherited_visibility flag so that the branches display without the system). We, therefore, are seeing a lot of Located URI records being retrieved outside of scope when we perform searches.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Mike Rylander (mrylander) wrote :

Can either of you confirm that 1) all the test searches are being performed at the CONS level (well, at any org that is a common ancestor of the LURI owners) and 2) this only occurs with act_as_copy enabled? That's what I'm currently seeing. Thanks!

Revision history for this message
Kathy Lussier (klussier) wrote :

Hi Mike,

1) The first time I replicated the problem, I retrieved a BR1 record when I was performing a search at SYS2. It didn't need to be a common ancestor.

2) The act_as_copy flag did not affect the results of my searches. I was able to replicate it with and without the flag enabled.


Revision history for this message
Mike Rylander (mrylander) wrote :

Kathy, that's fine. I believe I have addressed the issue. Please find the attached branch, which handles bib-level (source, luri) visibility test construction specially:;a=shortlog;h=refs/heads/user/miker/lp-1743650-more-luri-visibility-adjustments

tags: added: pullrequest webstaffclient
Revision history for this message
Kathy Lussier (klussier) wrote :

Thanks Mike! I tested the branch very briefly using the upgrade script. I haven't seen out-of-scope retrievals yet, but I came across another problem.

- I have BR2 set to OPAC invisible.
- has a Located URI owned by BR2, but also has a Located URI owned by SYS2
 - With this branch loaded, if my search is scoped to SYS2 , I do not retrieve the record as expected. This happens in the public catalog. The staff client search is still retrieving the record as expected.

Adding a note that the act_as_copy flag is disabled ATM.

Revision history for this message
Mike Rylander (mrylander) wrote :


I've force-pushed an update to the above branch. You can just run the upgrade script again, and then copy Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/ into place. After that, a service and apache restart should get you going. Note, I did have to restart memcache while testing to flush out a cached, stale org tree. You may need to do that, in addition to the apache and service restarts, between changes of the opac_visible flag on org units.

This new commit also contains explicit support for the opac.org_unit.non_inherited_visibility you mentioned in the initial description. That wasn't in place before, but it turns out that the behavior before this patch was to act as if that were enabled.

I have left some structural changes in place which, while not strictly necessary to address this bug, will benefit us if/when we add more bib-level visibility testing, such as based on the bre.owner field.


Revision history for this message
Kathy Lussier (klussier) wrote :

It works for me! I've signed off on the code and merged it to master and release 3.0.

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

Other bug subscribers

Remote bug watches

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