Preferred library holdings no longer return when searching at system level

[Bob Wicksall]

Evergreen 3.0.4

I logon as a patron and set my "Preferred search location" to Geneva public library. Next I search for Hobbit at the System level. In at least Evergreen 2.10 I get the following holdings information if Geneva has a copy:

   14 of 16 copies available at OWWL
   1 of 1 copy available at Geneva Public Library

In Evergreen 3.0 I just get:

   14 of 16 copies available at OWWL

Since the upgrade to 3.0 holdings information for "pref_lib" is no longer returned.

[Bob Wicksall (bwicksall)]

After a little digging it looks like this was caused by LP#1698206: Eliminate Staged Search.

unapi.biblio_record_entry_feed replaced unapi.bre in WWW/EGCatLoader/Util.pm. Util.pm is continuing to send 'pref_lib' but it's in the wrong parameter (title). Also, unapi.biblio_record_entry_feed and unapi.metabib_virtual_record_feed don't know what to do with pref_lib once they get it.

I was able to restore pref_lib functionality with the following hack on my test server. This has been very lightly.

*******************************
OpenILS/WWW/EGCatLoader/Util.pm
*******************************

--- Util.pm.orig 2018-03-20 15:45:29.232569315 -0400
+++ Util.pm 2018-03-20 15:47:02.348572718 -0400
@@ -406,7 +406,7 @@
             $unapi_args->{site},
             $unapi_args->{depth},
             $slimit,
- undef, undef, $unapi_args->{pref_lib}
+ undef, undef, undef, undef, undef, undef, undef, undef, $unapi_args->{pref_lib}
         ]}
     );

******************************
unapi.biblio_record_entry_feed
******************************

--- unapi.biblio_record_entry_feed.txt 2018-03-16 16:44:39.928533700 -0400
+++ unapi.biblio_record_entry_feed_pls.txt 2018-03-20 16:02:46.125997337 -0400
@@ -1,6 +1,6 @@
--- Function: unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, text, text, text, text, xml)
+-- Function: unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, text, text, text, text, xml, integer)

--- DROP FUNCTION unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, text, text, text, text, xml);
+-- DROP FUNCTION unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, text, text, text, text, xml, integer);

 CREATE OR REPLACE FUNCTION unapi.biblio_record_entry_feed(
     id_list bigint[],
@@ -16,7 +16,8 @@
     creator text DEFAULT NULL::text,
     update_ts text DEFAULT NULL::text,
     unapi_url text DEFAULT NULL::text,
- header_xml xml DEFAULT NULL::xml)
+ header_xml xml DEFAULT NULL::xml,
+ pref_lib integer DEFAULT NULL::integer)
   RETURNS xml AS
 $BODY$
 DECLARE
@@ -44,7 +45,7 @@
     xmlns_uri := COALESCE(transform.namespace_uri,xmlns_uri);

     -- Gather the bib xml
- SELECT XMLAGG( unapi.bre(i, format, '', includes, org, depth, slimit, soffset, include_xmlns)) INTO tmp_xml FROM UNNEST( id_list ) i;
+ SELECT XMLAGG( unapi.bre(i, format, '', includes, org, depth, slimit, soffset, include_xmlns, pref_lib)) INTO tmp_xml FROM UNNEST( id_list ) i;

     IF layout.title_element IS NOT NULL THEN
         EXECUTE 'SELECT XMLCONCAT( XMLELEMENT( name '|| layout.title_element ||', XMLATTRIBUTES( $1 AS xmlns), $3), $2)' INTO tmp_xml USING xmlns_uri, tmp_xml::XML, title;
@@ -78,5 +79,5 @@
 $BODY$
   LANGUAGE plpgsql STABLE
   COST 100;
-ALTER FUNCTION unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, text, text, text, text, xml)
+ALTER FUNCTION unapi.biblio_record_entry_feed(bigint[], text, text[], text, integer, hstore, hstore, boolean, text, te...

[Galen Charlton (gmc)]

Bob, I confirm that I am seeing the bug as well in Evergreen master, and I agree that the approach you outline is reasonable. I'll work up a patch.

[Galen Charlton (gmc)]

A patch is available at the tip of the user/gmcharlt/lp1756912_restore_preflib_copy_counts branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1756912_restore_preflib_copy_counts

[Cesar V (cesardv)]

Tested to work on current working master. Thanks Bob, Galen!
Signed off branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/cesardv/gmcharlt_lp1756912_restore_preflib_copy_counts-SIGNOFF

[Kathy Lussier (klussier)]

It works for me. I signed off on the commit and merged it to master and release 3.1. I encountered a merge conflict when trying to backport the fix to 3.0 and was unable to resolve it in the time I have available. Galen, could you take a look at it? I can give it another try when I'm back on the computer again.

Thank you Bob, Galen and Cesar!
Kathy

[Kathy Lussier (klussier)]

Now that I'm not rushing through the conflict resolution, I have a working branch based on 3.0 with the fix. However, since there was so much chance in this area, I'm going to test it on a 3.0 system before merging.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1756912_restore_preflib_copy_counts-merge-conflict

[Kathy Lussier (klussier)]

The 3.0 branch works for me as well and has been merged to rel_3_0.