site filter does not limit search

[Liam Whalen]

Evergreen 2.0.8
OpenSRF 2.0.1
PostgreSQL 9.0.4
Ubuntu 10.04

When I use the site() filter option in a search string it does not filter my searches by org unit.

For instance,

wikinomics site(ESS-SST-OTTAWA)

http://catalogue.nrcan.gc.ca/opac/en-CA/skin/nrcan-rncan/xml/rresult.xml?rt=keyword&tp=keyword&t=wikinomics%20site%28ESS-SST-OTTAWA%29&ft=&l=1&d=0&f=&av=

returns two hits, but the first one is only located in Quebec and should not be returned.

Using the org unit ID results in the same behaviour

wikinomics site(101)

http://catalogue.nrcan.gc.ca/opac/en-CA/skin/nrcan-rncan/xml/rresult.xml?rt=keyword&tp=keyword&t=wikinomics%20site%28101%29&ft=&l=1&d=0&f=&av=

[Michael Peters (mrpeters)]

It looks like Search.pm might be the place to start for this. Particularly:

    my $site;
    my $org = $ctx->{search_ou};
    if (defined($org) and $org ne '' and ($org ne $ctx->{aou_tree}->()->id) and not $query =~ /site\(\S+\)/) {
        $site = $ctx->{get_aou}->($org)->shortname;
        $query .= " site($site)";
    }

For what it's worth, I actually can't make this work either. Seems this may be completely busted. Shame, because its a nice shortcut!

[Lebbeous Fogle-Weekley (lebbeous)]

Hey Michael, I'm afraid that's TPAC code you pointed out, and the bug report refers to JSPAC.

The problem could be in any of three general places: actually in QueryParser (although this is less likely than the other two), JSPAC and TPAC.

We should find out whether we can duplicate this in JSPAC and TPAC separately, and note that here, so we know where to look.

[Michael Peters (mrpeters)]

Lebbeous, that's great info. Thanks. I think it's actually broken in both iterations of the OPAC.

In TTPAC (master.evergreen.lib.in.us) and 2.2 beta2 (testing.evergreen.lib.in.us) I tried:

baseball site(2)

It resulted in an Internal Server Error.

[Wed Apr 11 14:02:03 2012] [error] [client 208.119.0.30] egweb: Context Loader error: Can't call method "ou_type" on an undefined value at /usr/local/share/perl/5.10.1/OpenILS/WWW/EGCatLoader/Search.pm line 137.\n, referer: http://master.evergreen.lib.in.us/eg/opac/advanced

In JSPAC, the search performs without error, but it isn't scoped properly. I get results from all org units, not just aou.id=2.

[Michael Peters (mrpeters)]

In order to properly categorize this (Valid vs Won't Fix) I think we need to make a ruling on whether or not it is valid to use an ID value instead of a shortname in the site(foo) limiter as we did historically.

For what it's worth, site(foo) in TPAC works OK, it's only when you pass an ID that it results in an Internal Server Error. Since JSPAC allowed an ID, I think I would lean towards saying TPAC should as well.

[Galen Charlton (gmc)]

Removing bitesize tag, given recent QP work and discussion about it that would make this bug a mare's nest for a newbie.

[Josh Stompro (u-launchpad-stompro-org)]

Tested the site() search on a 2.7.1 system and can confirm that anything but a correct org unit shortname/Policy Code results in an Internal Server Error.

It does look like there is no validation of the site value in
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=19f3a258e90b21c2d462fb0f360de9829270c117;hb=HEAD#l134

151 if(!$site) {
152 ($site) = ($query =~ /site\(([^\)]+)\)/);
153 $site ||= $ctx->{aou_tree}->()->shortname;
154 }

What would be the most sane thing to do if the value of site isn't valid? Set to the current default org. Set to 1.

It seems like there should be a check to see if the site value is an int, if it is then look up that org unit and replace $site with the shortname. If the lookup fails then treat the value as a shortname and check it for validity. No reason a shortname couldn't be a number right? Then if that fails, set to the default, or just unset site so it acts like it isn't there.