Bug 4276 - "Related subjects" search doesn't work with XSLT on and chained subject terms
Summary: "Related subjects" search doesn't work with XSLT on and chained subject terms
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: 3.4
Hardware: All All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Jared Camins-Esakov
QA Contact: Bugs List
URL:
Keywords:
: 5220 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-02-26 01:36 UTC by Chris Cormack
Modified: 2019-06-27 09:24 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed patch. (2.72 KB, patch)
2010-03-20 01:21 UTC, Chris Cormack
Details | Diff | Splinter Review
Proposed fix for HEAD (3.01 KB, patch)
2010-09-15 15:13 UTC, Owen Leonard
Details | Diff | Splinter Review
Signed-off proposed patch (23.26 KB, application/octet-stream)
2011-03-21 19:44 UTC, Jared Camins-Esakov
Details
Follow-up patch (3.92 KB, patch)
2011-04-05 12:14 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:25:16 UTC


---- Reported by pasi.korkalo@oululainen.com 2010-02-26 13:36:34 ----

Related subjects doesn't work right when using XSLTDetailsDisplay. Clicking on chained subject terms only does the search with the first term in the chain. For example clicking on "world-music Portugal" only searches with "su:world-music" instead of "su:world-music and su:Portugal" which is what you'd expect.



---- Additional Comments From oleonard@myacpl.org 2010-02-26 15:07:07 ----

This problem exists in both the OPAC and staff client XSL detail pages in HEAD.



---- Additional Comments From gcollum@gmail.com 2010-02-28 21:08:06 ----

I was able to get the desired affect by replacing

<xsl:attribute name="href">/cgi/bin/koha/catalogue/search.pl?1=su:<xsl:value-of select="marc:subfield[@code='a']"/></xsl.attribute>

in MARC21slim2intranetDetail.xsl with

<xsl:attribute name="href">/cgi-bin/koha/catalogue/search.pl?q=su:<xsl:call-template name="chopPunctuation">
        <xsl:with-param name="chopString">
            <xsl:call-template name="subfieldSelect">
                <xsl:with-param name="codes">abcdvxyz</xsl:with-param>
            </xsl:call-template>
        </xsl:with-param>
    </xsl:call-template>
</xsl:attribute>

But if any keywords were added to the link, other than what was in 650 subfield a, no results were returned.  Are other subfields in 650 indexed?  Is it just my setup?




---- Additional Comments From jwagner@ptfs.com 2010-03-19 18:15:46 ----

We did some experimenting with manual searches and indexes today.  Standard Koha seems to deliver all the 6xx fields indexed with all subfields, like this:

melm 650        Subject,Subject:p

We tried adding Subject:w as a setting, and reindexed.  That didn't make any difference -- searching either 

su,phr: College teachers United States Periodicals

or

su: College teachers United States Periodicals

does not get any results.  I took a look at the way the non-XSLT search works, and it's rather questionable:

su: College teachers and su: United States and su: Periodicals

This works and gets results, but it doesn't limit the results to records with that as the entire subject entry "College teachers United States Periodicals" in different subfields.  Rather, it's finding titles with a subject subfield of College Teachers and perhaps another subject subfield in a different 6xx of United States, etc.  Is that the best approach?  Isn't there any way to say only search for this entire string in one 6xx field?

I haven't tried any code change yet with XSLT -- I want to understand how the search works first.





---- Additional Comments From gcollum@gmail.com 2010-03-19 23:12:49 ----

I was experimenting some more.

The code above creates a url in the form of "search.pl?q=su:history+united+states+civil+war" and does not return any hits.  

If the url takes the form of "search.pl?idx=su&q=history+united+states+civil+war" hits are returned.

This is getting closer to the desired affect, but a phrase search would be better.  The keyword search would still produce some false hits.





---- Additional Comments From gcollum@gmail.com 2010-03-20 01:21:38 ----

Created an attachment
Proposed patch.

Here's a proposed patch.  It also adds subfield b to a 710 (Corporate Author) link.  I don't think we would need anything other than subfield b, but I'm not a cataloger.

The Intranet still needs to be looked at, but it has some other problems.  The links in the detail page are pointing to the opac.  I've submitted a patch to fix this, but it has not yet been pushed.  (http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4285)



---- Additional Comments From jwagner@ptfs.com 2010-03-22 18:56:25 ----

collum, following up on our IRC discussion so it doesn't get lost -- there are a couple of problems with your patch as is.  One is that if a subject string has a paren in it, like Science Study and teaching (Higher) United States, it doesn't find any results.  The same string without the paren works -- Science Study and teaching Higher United States.  

I don't know if there are other special chars found in subject terms that should be stripped.  Any catalogers around?

The other problem has to do with including the 710 corporate author in the subject search.  If I understood correctly, you did so to fix a similar problem with other authority links, but you were going to look at how to limit subjects to subject index, etc.

Overall, it works nicely and is a big improvement.  Thanks for your work!





---- Additional Comments From gcollum@gmail.com 2010-03-22 20:14:00 ----

jwagner: The 710 is unrelated to the subject search.  Sorry for the confusion. The search behavior of the subject links, the bug, is also present in other authority links. 

For instance, an author(700) that has the data ($a Feitelson, Lorser,$d 1898-), would not include the date, subfield d, in the url of the link, and currently if it did, it would not return results.

 



---- Additional Comments From jwagner@ptfs.com 2010-03-22 20:19:37 ----

That's what I thought you were saying, thanks.  I started looking at how to strip out parens (and anything else) but haven't gotten very far.  I was pointed to this site

http://www.w3schools.com/xpath/xpath_functions.asp#string

for some XSLT string handling/substitution functions.  I'll investigate further unless you beat me to it.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:25 UTC  ---

This bug was previously known as _bug_ 4276 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4276
Imported an attachment (id=1972)

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was pasi.korkalo@oululainen.com.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member jwagner@ptfs.com does not have an account here
The original submitter of attachment 1972 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2010-09-15 14:36:08 UTC
*** Bug 5220 has been marked as a duplicate of this bug. ***
Comment 2 Owen Leonard 2010-09-15 15:13:34 UTC
Created attachment 2629 [details] [review]
Proposed fix for HEAD
Comment 3 Nicole C. Engard 2010-12-16 15:37:03 UTC
I had a customer point this out the other day as a 'feature.'  Most patrons don't give a hoot about what order the headings are entered.  If they want Fiction in the United States then su:Fiction and su:United States is what they want to happen when searching - they don't care if there are other things after that in the heading.  Now I know that the patch was already written and this is not the majority opinion, but it is this cataloger opinion that this is a usability feature for our patrons and should only be changed in the staff client.
Comment 4 Nicole C. Engard 2011-03-19 15:04:18 UTC
signed off on jared's patch
Comment 5 Jared Camins-Esakov 2011-03-21 19:44:07 UTC
Created attachment 3385 [details]
Signed-off proposed patch

This fix adds a new syspref, so that libraries that want the current behavior can keep it, and libraries that don't, don't have to.
Comment 6 Jared Camins-Esakov 2011-03-25 02:42:16 UTC
Nicole tested this, and confirmed it works properly even without the patch for bug 5868, so I'm removing the dependency.
Comment 7 Chris Cormack 2011-03-27 20:56:44 UTC
Pushed please test
Comment 8 Jared Camins-Esakov 2011-03-28 17:19:05 UTC
This works properly for me.
Comment 9 Jared Camins-Esakov 2011-04-02 19:42:42 UTC
I used the wrong characters for quoting. I should have used curly braces instead of double quotes. Some searches using double quotes will fail (the problem seems to be punctuation). Follow-up patch to come.
Comment 10 Jared Camins-Esakov 2011-04-05 12:14:33 UTC
Created attachment 3673 [details] [review]
Follow-up patch
Comment 11 Chris Cormack 2011-04-06 22:54:58 UTC
Pushed, please test,

Thanks for your work on this Jared, its looking much better now ;)
Comment 12 Jared Camins-Esakov 2011-07-08 14:35:11 UTC
As far as is possible, this is now working. Completely working tracings would require a new indexing configuration. Since that is outside the scope of this bug, I will close it.