holdings_xml-uris is broken as is holdings_xml-full

Bug #898427 reported by James Fournie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned

Bug Description

holdings_xml-uris doesn't seem to work quite right

The method checks for a value of $flesh eq "uris", however it seems that in that scenario the value is actually 2. The attached branch corrects that, as well as uses org_unit_ancestors to retrieve the URIs to populate the XML as correcting in git commit ba47ecc6196055886ad6f23284819be5dec8448d

Testing would be appreciated

working/user/jamesrf/lp898427_holdingsxml_uris

Tags: supercat
James Fournie (jfournie)
description: updated
James Fournie (jfournie)
description: updated
tags: added: pullrequest supercat
description: updated
Revision history for this message
Dan Scott (denials) wrote :

First things first: What version of Evergreen are you reporting this for?

tags: removed: pullrequest
Revision history for this message
James Fournie (jfournie) wrote :

The bug in question is confirmed in Evergreen 2.0, and isn't likely fixed in master. The branch is for master only.

I've force-pushed a fresh version which includes the fix for a problem with holdings_xml-full.

It affects unAPI as used by BibTemplate.

See OpenILS:Application:SuperCat +2149

    if ($flesh and $flesh eq 'uris') {
        %subselect = (
            owning_lib => \@ou_ids,
            '-exists' => {
                from => { auricnm => 'auri' },
                where => {
                    call_number => { '=' => {'+acn'=>'id'} },
                    '+auri' => { active => 't' }
                }
            }
        );
    }

This block seems to expect a value of 'uris' but is getting passed a 2 by OpenILS::WWW::Supercat. See commit f2b822f8 -- that changed the value from 'uris' to 2.

Here's a some examples of it being broken:

http://evergreen.lib.in.us/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/17593755[10]/ISLI/2&format=holdings_xml-uris&locale=en-US&dojo.preventCache=1323391615672

http://methuen.mvlc.org/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/1230661[10]/MVLC/0&format=holdings_xml-uris&locale=en-US&dojo.preventCache=1323391615672

Changing the "uris" to 2 fixes this.

Additionally, the -full doesn't actually seem to work -- it doesn't include the URIs:

http://evergreen.lib.in.us/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/17593755[10]/ISLI/2&format=holdings_xml-full&locale=en-US&dojo.preventCache=1323391615672

http://methuen.mvlc.org/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/1230661[10]/MVLC/0&format=holdings_xml-full&locale=en-US&dojo.preventCache=1323391615672

summary: - holdings_xml-uris does not respect new corrected URI visibility
+ holdings_xml-uris is broken as is holdings_xml-full
Revision history for this message
Dan Scott (denials) wrote :

Tested and confirmed on our production 2.1 system. Applied to master and rel_2_1. Many thanks, James!

Changed in evergreen:
milestone: none → 2.2.0alpha2
status: New → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.