[OPEN-ILS-DEV] URI scoping in Evergreen

[Kathy Lussier]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140717/ddae5f69/attachment.htm>