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
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.
I don't think this is an enhancement - seems more like a bug to me.
This is still an issue in master, 3.12 and 3.10.
The same is true for shelving locations by the way - it seems that any similar codes are searched together.
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.
Yeah this is a pet peeve of mine.
(In reply to Katrin Fischer from comment #5) > 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. This sounds like treating a bug as a feature :/