[OPEN-ILS-DEV] Including "preferred library" in search for located URIs

[Dan Scott]

On Fri, Mar 23, 2012 at 8:28 AM, Kathy Lussier <klussier at masslnc.org> wrote:
> Thanks Dan!
>
> I also wanted to add that the use case where we see this feature as being of
> most benefit is when a user has set their search library to the entire
> consortium. Many of our at-home users start off by searching the consortium,
> and giving them the ability to retrieve electronic resources owned by their
> home libraries will be a big plus.
>
> Kathy
>
>>>-----Original Message-----
>>>From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-
>>>dev-bounces at list.georgialibraries.org] On Behalf Of Dan Scott
>>>Sent: Friday, March 23, 2012 3:39 AM
>>>To: open-ils-dev at list.georgialibraries.org
>>>Subject: [OPEN-ILS-DEV] Including "preferred library" in search for
>>>located URIs
>>>
>>>I've been asked to teach search to include the user's "preferred search
>>>library" (as set in search preferences, falling back to home OU) in
>>>searches, specifically for the purposes of ensuring that located URIs
>>>at
>>>the user's preferred library would trigger hits where physical copies
>>>would be out of scope.
>>>
>>>Practical example:
>>>
>>>1. User sets preferred search library to BR1.
>>>
>>>2. They jump onto the catalogue, log in (which changes their search org
>>>   to their preferred search library of BR1), but then for some reason
>>>   change their search org in the org selector to BR3.
>>>
>>>3. They issue a search for "Harry Potter and the Philosopher's Stone".
>>>   BR3 doesn't hold any copies or have any located URIs, but SYS1
>>>(BR1's
>>>   parent) has a PotterMore licence and has added their 856 $9 SYS1 to
>>>a
>>>   bib record.
>>>
>>>As it currently stands, User is out of luck; they won't see any hits in
>>>search results as there are no copies or located URIs in the BR3 scope.
>>>
>>>The proposed enhancement would, however, make the search results
>>>contain
>>>a hit for "Harry Potter and the Philosopher's Stone" at the user's
>>>preferred search library. With the enhancements to TPAC search results
>>>& record details copy / located URI display in
>>>https://bugs.launchpad.net/evergreen/+bug/907056 the located URI at the
>>>preferred library would then be displayed.
>>>
>>>So, two questions:
>>>
>>>1) Any strong resistance to the addition of this feature?
>>>
>>>2) My rough implementation plan would be:
>>>
>>>   a) Add another parameter to search.query_parser_fts() :
>>>param_pref_ou INT
>>>      - that would simply concatenate the pref_ou ancestors onto
>>>      luri_org_list (deduping, naturally)
>>>
>>>   b) Then make the existing 10-parameter search.query_parser_fts()
>>>function
>>>      a wrapper that calls the new 11-parameter function.
>>>
>>>   c) Then make O:A:Storage:Publisher::query_parser_fts() capable of
>>>calling
>>>      the 11-param function if param_pref_ou has a value.
>>>
>>>   d) Then teach callers of open-ils.storage.query_parser_search to
>>>pass in
>>>      a pref_ou argument (when appropriate).
>>>
>>>Any thoughts / concerns before I sally forth?
>

Okay, hearing no objection, I've pushed a first-cut working branch to
user/dbs/preferred_lib_located_uris that adds this capability.

Thus far it has only lightly been tested in TPAC, but in theory should
work in JSPAC. The major difference from the proposed plan was that I
simply added the 11th parameter to search.query_parser_fts() and made
it default to NULL; then dropped the 10-parameter version.