---- Reported by email@example.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 firstname.lastname@example.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 email@example.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">
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 firstname.lastname@example.org 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
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 email@example.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 firstname.lastname@example.org 2010-03-20 01:21:38 ----
Created an attachment
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 email@example.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 firstname.lastname@example.org 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 email@example.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
for some XSLT string handling/substitution functions. I'll investigate further unless you beat me to it.
--- Bug imported by firstname.lastname@example.org 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: email@example.com.
Previous reporter was firstname.lastname@example.org.
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
CC member email@example.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: firstname.lastname@example.org.
*** Bug 5220 has been marked as a duplicate of this bug. ***
Created attachment 2629 [details] [review]
Proposed fix for HEAD
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.
signed off on jared's patch
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.
Nicole tested this, and confirmed it works properly even without the patch for bug 5868, so I'm removing the dependency.
Pushed please test
This works properly for me.
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.
Created attachment 3673 [details] [review]
Pushed, please test,
Thanks for your work on this Jared, its looking much better now ;)
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.