Bug 37167 - Fix mapping call number searches to Z39.50
Summary: Fix mapping call number searches to Z39.50
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Phil Ringnalda
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-24 04:26 UTC by Phil Ringnalda
Modified: 2024-08-15 22:19 UTC (History)
1 user (show)

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


Attachments
Bug 37167: Fix mapping call number searches to Z39.50 (1.74 KB, patch)
2024-06-25 04:06 UTC, Phil Ringnalda
Details | Diff | Splinter Review
Bug 37167: Fix mapping call number searches to Z39.50 (1.79 KB, patch)
2024-06-26 21:48 UTC, David Nind
Details | Diff | Splinter Review
Bug 37167: Fix mapping call number searches to Z39.50 (2.12 KB, patch)
2024-06-28 15:27 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Ringnalda 2024-06-24 04:26:43 UTC
If you do an advanced search for Call number, your search will be for &idx=callnum, but the code in catalogue/search.pl that creates $z3950par to pass to z3950_search_args to eventually fill the form if you use the Z39.50/SRU Search button in your search results thinks that the index for callnum searches is still the one it was 15 years ago, lcn,phr, so instead of getting your search term filled in the "Dewey:" field (which isn't, it's a generic call number search), you get it in the "Title:" field.
Comment 1 Phil Ringnalda 2024-06-25 04:06:32 UTC
Created attachment 168048 [details] [review]
Bug 37167: Fix mapping call number searches to Z39.50

When you do an advanced search for call number, your search uses the index
callnum, but the code that maps your search to a possible Z39.50 search
still uses the index lcn,phr which was last used 15 years ago, so it's
treated as an unknown index and mapped to the Title field in the Z39.50
search form.

Test plan:
1. Click Search in the top menu to load Advanced Search
2. Change the dropdown menu for the first input from Keyword to Call
   Number, and paste TT174.3 in the input and search
3. Find the Z39.50/SRU search button in your results and click it
4. Note that your search was filled in the Title field
5. Apply patch, reset_all
6. Repeat steps 1-3, note that your search was filled in the Dewey field
7. Choose the server Library of Congress SRU and search
8. Note that even though we labelled it Dewey and you searched for an
   LC call number, your results are things with that call number in 050,
   the LC call number field.
Comment 2 Phil Ringnalda 2024-06-25 04:07:31 UTC
Filed bug 37168 for fixing the inaccurate "Dewey" label.
Comment 3 David Nind 2024-06-26 21:48:59 UTC
Created attachment 168183 [details] [review]
Bug 37167: Fix mapping call number searches to Z39.50

When you do an advanced search for call number, your search uses the index
callnum, but the code that maps your search to a possible Z39.50 search
still uses the index lcn,phr which was last used 15 years ago, so it's
treated as an unknown index and mapped to the Title field in the Z39.50
search form.

Test plan:
1. Click Search in the top menu to load Advanced Search
2. Change the dropdown menu for the first input from Keyword to Call
   Number, and paste TT174.3 in the input and search
3. Find the Z39.50/SRU search button in your results and click it
4. Note that your search was filled in the Title field
5. Apply patch, reset_all
6. Repeat steps 1-3, note that your search was filled in the Dewey field
7. Choose the server Library of Congress SRU and search
8. Note that even though we labelled it Dewey and you searched for an
   LC call number, your results are things with that call number in 050,
   the LC call number field.

Signed-off-by: David Nind <david@davidnind.com>
Comment 4 David Nind 2024-06-26 22:02:13 UTC
Testing notes (using KTD):

1. For step 5, only a restart_all is required.
Comment 5 Phil Ringnalda 2024-06-26 22:06:03 UTC
I reset_all all the time when I mean restart_all, I'd be surprised if that's the first time I've done it in a test plan :)
Comment 6 David Nind 2024-06-27 01:53:47 UTC
(In reply to Phil Ringnalda from comment #5)
> I reset_all all the time when I mean restart_all, I'd be surprised if that's
> the first time I've done it in a test plan :)

No problem! Sometimes (very occasionally I find) a reset_all is required. I just add the testing notes for my future self, but they may be of use to others as well.
Comment 7 Martin Renvoize 2024-06-28 15:27:38 UTC
Created attachment 168263 [details] [review]
Bug 37167: Fix mapping call number searches to Z39.50

When you do an advanced search for call number, your search uses the index
callnum, but the code that maps your search to a possible Z39.50 search
still uses the index lcn,phr which was last used 15 years ago, so it's
treated as an unknown index and mapped to the Title field in the Z39.50
search form.

Test plan:
1. Click Search in the top menu to load Advanced Search
2. Change the dropdown menu for the first input from Keyword to Call
   Number, and paste TT174.3 in the input and search
3. Find the Z39.50/SRU search button in your results and click it
4. Note that your search was filled in the Title field
5. Apply patch, reset_all
6. Repeat steps 1-3, note that your search was filled in the Dewey field
7. Choose the server Library of Congress SRU and search
8. Note that even though we labelled it Dewey and you searched for an
   LC call number, your results are things with that call number in 050,
   the LC call number field.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 8 Martin Renvoize 2024-06-28 15:28:08 UTC
Thanks for the quick work here Phil, 

All working as described.

Passing QA
Comment 9 Katrin Fischer 2024-07-01 16:35:30 UTC
Dewey is better than title for sure, but we are pretending that all libraries use Dewey. In Germany almost no library uses Dewey. Even in the US some might be using LOC I think?

I wonder if this automatism really makes sense or won't be a nuisance for some libraries that would prefer if there was no auto-fill at all?
Not sure what we could do, to make this smarter. 

Just pondering to maybe result in a new bug with some ideas on how to make this a bit smarter.
Comment 10 Phil Ringnalda 2024-07-01 16:56:34 UTC
Conveniently, Dewey isn't Dewey, it's actually LC.

It would have been cleaner if I discovered everything broken with this feature before I filed the first bug or wrote the first patch, but since no generic call number search actually exists in Z39.50, bug 37168 is heading toward making this prefill keyword, making Dewey actually search Dewey, and people who know their callnum search was for either LC or Dewey can copy-paste from keyword to the appropriate flavor, while people with call numbers that are neither can leave it in keyword.
Comment 11 Katrin Fischer 2024-07-01 16:58:56 UTC
Pushed for 24.11!

Well done everyone, thank you!
Comment 12 Phil Ringnalda 2024-07-01 21:27:57 UTC
Preferring no auto-fill at all is easy: don't do a call number search and then continue to Z39.50 from the results of that search :)

Replace via Z39.50 doesn't prefill call numbers, there's nothing in biblio/biblioitems from which they could, so this only comes up if you explicitly say in advanced search that you are searching call number, and then go to Z39.50 from those results rather than going to Cataloging - New from Z39.50 when you've given up on your search results and want to start from scratch.