Hi Mike and Liam,
Here is what I was trying to communicate. Aside from cases where
we explicitly do not want URIs being displayed, the records should
be scoped according to the fenced of area of the URI. So, if the
Search OU or Pref OU falls within the fencing, then the record
should be returned in the search results. However, copies still
need to be considered because a record might have a copy owned by
one library which does not have a 856 $9, and it might also have a
library with an 856$9. In that case, the record needs to be
displayed in the search results for the first library in the
manner that copy visibility currently works. In the second case
the record needs to be displayed in the manner we are currently
discussing. I believe the luri_act_as_copy flag currently removes
records with copies but not 856 $9 from the results when there are
non-relevant (to the search or pref OU) 856 $9 values within the
record.
luri_act_as_copy absolutely should /not/ be removing records with
visible copies but no visible 856$9. If that is happening, it is a
bug and I would be very interested in seeing an example so I can
squash it.
For non-deleted records, visibility testing is designed to be
inclusive, not exclusive, so if anything causes a record to be
included in the result set (visible copy, visible LURI, transcendent,
completely empty (for staff)) then it is included -- period.
I just tested this on a master system and it worked as expected. With
the luri_act_as_copy flag enabled, I was able to find this record -
http://jasondev.mvlcstaff.org/eg/opac/record/1559434 - when I was scoped
to the library that had a copy record and when I was scoped to the
library identified in subfield 9.
