Preferred library holdings no longer return when searching at system level

Bug #1756912 reported by Bob Wicksall on 2018-03-19
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned

Bug Description

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) wrote :
Download full text (5.4 KiB)

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

Read more...

Galen Charlton (gmc) on 2018-03-21
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
tags: added: opac regression
Galen Charlton (gmc) wrote :

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.

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

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

Changed in evergreen:
milestone: none → 3.0.5
tags: added: pullrequest
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
milestone: 3.0.5 → 3.0.6
Changed in evergreen:
milestone: 3.0.6 → 3.0.7
Changed in evergreen:
milestone: 3.0.7 → 3.0.8
Kathy Lussier (klussier) wrote :

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) wrote :

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) wrote :

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

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers