I have applied the patch to an upgraded system and am seeing the following for a record with a located uri:
In the staff client:
- The record is retrieved in the scope of the located uri
- The record is retrieved in the cons scope
- The record is retrieved in another branch's scope but the link does not display
In the public catalog:
- The record is retrieved in the scope of the located uri
- The record is retrieved in the cons scope
- The record is not retrieved in another branch's scope
This behavior is the same for existing, new, and edited records.
The problem I see with the patched behavior is the staff client behavior where the record appears in a scope that does not match the located uri. This will result in a lot of irrelevant hits in scoped searches. Otherwise, the visibility is behaving as expected.
We have the opac.located_uri.act_as_copy flag enabled.
Echoing a comment from lp 1736419 here:
I have applied the patch to an upgraded system and am seeing the following for a record with a located uri:
In the staff client:
- The record is retrieved in the scope of the located uri
- The record is retrieved in the cons scope
- The record is retrieved in another branch's scope but the link does not display
In the public catalog:
- The record is retrieved in the scope of the located uri
- The record is retrieved in the cons scope
- The record is not retrieved in another branch's scope
This behavior is the same for existing, new, and edited records.
The problem I see with the patched behavior is the staff client behavior where the record appears in a scope that does not match the located uri. This will result in a lot of irrelevant hits in scoped searches. Otherwise, the visibility is behaving as expected.
We have the opac.located_ uri.act_ as_copy flag enabled.