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

[Kathy Lussier]

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.

[Mike Rylander (mrylander)]

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!

[Kathy Lussier (klussier)]

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.

Sorry!

[Mike Rylander (mrylander)]

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:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1743650-more-luri-visibility-adjustments

[Kathy Lussier (klussier)]

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.
- http://mlnc1.noblenet.org/eg/opac/record/250 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.

[Mike Rylander (mrylander)]

Kathy,

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/QueryParser.pm 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.

Thanks!

[Kathy Lussier (klussier)]

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