Bug 7456 - Itemtype codes with hyphens and spaces can cause unexpected search results
Summary: Itemtype codes with hyphens and spaces can cause unexpected search results
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-20 21:29 UTC by Thatcher Rea
Modified: 2021-11-12 18:56 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thatcher Rea 2012-01-20 21:29:23 UTC
When performing a search for itype "BOOK", items with the itype code of "E-BOOK" appears in the opac search results.

The itype codes are defined as follows:

http://screencast.com/t/6I162l0m3MOm

I created a new itype code of "E-BK", applied it to an item, and it no longer displays in a search limited to itype code "BOOK".

Similarly named itype codes are being included in search results. It didn't catch the other itypes, because their codes do not include the string of "book".

How to test:

1. create an itype "test"
2. create anohter itype code "e-test"
3. create 2 items (one with itype test, one with itype e-test)
4. index
5. do an advanced search limited by itype 'test'

You should get both items. 

:T
Comment 1 Thatcher Rea 2012-01-20 22:09:55 UTC
Adding from the IRC logs:

(3:34:35 PM) jcamins: If they use EBOOK, that might work. I'm not sure.
(3:34:55 PM) trea: you think the issue is the hyphen?
(3:35:05 PM) jcamins: It makes it a separate word.
(3:36:22 PM) jcamins: Combined with the fact that ,phr doesn't actually use the phrase indexes, it just uses unfuzzy matching on the word index, BOOK logically *should* find results for E-BOOK.
(3:36:30 PM) jcamins: I mean, given the way C4::Search works.
(3:36:40 PM) jcamins: Since C4::Search is broken.
(3:37:00 PM) jcamins: Because obviously that's not what it should be doing if the system worked the way we wanted it to.
(3:38:09 PM) trea: so, to summate, dont' do that!
(3:38:21 PM) trea: use unique strings for itype codes
(3:38:55 PM) jcamins: Right.
(3:39:17 PM) jcamins: Use unique strings for *all* authorized values.
(3:39:44 PM) trea: add it to the bug :P
(3:39:46 PM) jcamins: Or at least don't use any hyphens, if you feel you need similar codes.
Comment 2 Nicole C. Engard 2013-01-28 17:11:10 UTC
I don't think this is an enhancement - seems more like a bug to me.
Comment 3 Nicole C. Engard 2013-06-02 18:37:10 UTC
This is still an issue in master, 3.12 and 3.10.
Comment 4 Nicole C. Engard 2014-03-05 14:41:26 UTC
The same is true for shelving locations by the way - it seems that any similar codes are searched together.
Comment 5 Katrin Fischer 2019-04-28 21:55:10 UTC
I don't think 'fixing' search would be easy here, I have to admit we also rely on that behaviour in at least one case. What we could do is add a warning when adding authorised values and item type codes that using hyphens and spaces can have unexpected consequences for search.