[OPEN-ILS-DEV] URI scoping in Evergreen

liam.whalen at bc.libraries.coop liam.whalen at bc.libraries.coop
Thu Jul 17 11:58:49 EDT 2014


Quoting Kathy Lussier <klussier at masslnc.org>:

> 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.

Thank you for testing Kathy.  It must be something specific to Sitka's  
code then.

Liam


More information about the Open-ils-dev mailing list