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: [email protected] [mailto:open-ils- >>[email protected]] On Behalf Of Dan Scott >>Sent: Friday, March 23, 2012 3:39 AM >>To: [email protected] >>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?
