[Bug 37889] New: Item search: collection search doesn’t work correctly when searching 'collection is not'
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Bug ID: 37889 Summary: Item search: collection search doesn’t work correctly when searching 'collection is not' Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Searching Assignee: koha-bugs@lists.koha-community.org Reporter: kati.sillgren@porvoo.fi QA Contact: testopia@bugs.koha-community.org itemsearch.pl Item search and searching 'collection is not' does not take into account items that do not have a collection code. Not all items have a collection code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Katariina Pohto <katariina.pohto@ouka.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katariina.pohto@ouka.fi --- Comment #1 from Katariina Pohto <katariina.pohto@ouka.fi> --- This seems to happen with some other values that can be NULL. In the drop down menu with the barcode placeholder there can be several different options working the same way, for example age restriction or series. If you search items while selecting these as "is not", the results will not include the items that have a NULL value. It seems to be the way SQL works. Even reports will not give you the NULL results if you search for items with (CCODE != collection) but you can circumvent it using (CCODE IS NULL OR CCODE !=CCODE). This is how our librarians think it should work in item search. (And if we changed this logic it would still be possible to do the CCODE search the way it was, by selecting 'Collection IS' and making the multiple choice of all the collections but the ones excluded.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|new feature |normal CC| |emmi.takkinen@koha-suomi.fi -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- *** Bug 41726 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I said this over on bug 41726 before it got closed as a dupe: hardcoding behavior to make item search silently differ from base SQL seems like it will create confusion in the long run. I'd prefer to see this addressed with some mechanism on the item search page to explicitly ask the search to include NULL values in the results for an IS NOT search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Adding the step by step test plan here from bug 41726: To test: * Create a new location by adding a new entry to the LOC authorised value category (so it's not used otherwise) * Add 2 items to a record Item A: has the location with the new value Item B: has no location Note the title of your record * Search using the item search: Title: your title (don't forget to truncate with %) Verify your 2 items are found * Amend the search and add to the search criteria: Location is not <your new location> * Verify that you get NO results. Expected behavior: The item with no location should be found In SQL we can see the difference: select * from items where location != "something"; Results including NULL/empty locations: select * from items where location != "something" OR location is NULL; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Catrina Berka <catrina@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |catrina@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 trevor.diamond@mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond@mainlib.org --- Comment #5 from trevor.diamond@mainlib.org --- Could this be achieved by adding an option "Blank/Null/Empty" (wording to be determined) in addition to all the other choices? So in addition to all the authorized values being given as a choice, include one for "blank" value that would allow you specifically search for that field being null (or include it along with other choice entries). That would make it seem more intuitive for the user as an option instead of hardcoding behavior one way or another. The option should be at the top of the list, in order to avoid getting lost in all the other options. For example, a list of collections Authorized Values is Archives, Allen Room, Award Winners, Biography, Biology, etc. and the options in item search would be Blank Allen Room Archives Award Winners etc. The alphabetized list, but with the "blank" option first (and thus being obvious for users regardless of how many other choices might be available in any of the drop downs). This would make sense to apply to all the standard item search fields, but I'd also like to see it as an option for the custom item search fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I would maybe change the label to "No location" but it could work. I think it would be very helpful for libraries to be able to find/search items with no locations, collections etc. - I am not stuck on how to do it as long as we find a way that has good usability. :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 --- Comment #7 from Kati Sillgren <kati.sillgren@porvoo.fi> --- For example “Collection is not” is needed and useful when You need to search items where location is Adults and chosen collection is not included into search. Items may have some other collections that include to the search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Nathalie SAVARIT <nathalie.savarit@univ-amu.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nathalie.savarit@univ-amu.f | |r -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42196 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42196 | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37889 Chip Halvorsen <Chip.Halvorsen@WestlakeLibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Chip.Halvorsen@WestlakeLibr | |ary.org -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org