Summary: | Cannot search for patrons using second surname/firstname | ||
---|---|---|---|
Product: | Koha | Reporter: | Tomás Cohen Arazi <tomascohen> |
Component: | Patrons | Assignee: | Jonathan Druart <jonathan.druart> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | chris, gmcharlt, gwilliams, jonathan.druart, katrin.fischer, kyle.m.hall, veron |
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: |
Bug 14871: Extend the patrons search to search like %$term% (checkout tab)
[Signed-off] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) [SIGNED OFF] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) [PASSED QA] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) |
Description
Tomás Cohen Arazi
2015-09-22 14:03:32 UTC
Created attachment 42786 [details] [review] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) The patrons search used by the checkout tab and the autocomplete is not the same as the "search patrons" tab. The main difference is the "contain" vs "start with". So that if you have a patron with a patron with a surname "foo bar" and you search for "foo bar", the autocomplete and the result of a search by the checkout tab will search for "foo%" or "bar%" which won't return the patron you are search for. This patch replaces both autocomplete and checkout tab searches with a "contain" search. The search will be "%foo%" or "%bar%". Note that on big DB, this can cause unexpected results. Test plan: Create a patron with a surname "foo bar" Search for "bar" using the checkout tab. You should see the patron in the autocomplete result and the result page after submitting the search form. Created attachment 42799 [details] [review] [Signed-off] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) The patrons search used by the checkout tab and the autocomplete is not the same as the "search patrons" tab. The main difference is the "contain" vs "start with". So that if you have a patron with a patron with a surname "foo bar" and you search for "foo bar", the autocomplete and the result of a search by the checkout tab will search for "foo%" or "bar%" which won't return the patron you are search for. This patch replaces both autocomplete and checkout tab searches with a "contain" search. The search will be "%foo%" or "%bar%". Note that on big DB, this can cause unexpected results. Test plan: Create a patron with a surname "foo bar" Search for "bar" using the checkout tab. You should see the patron in the autocomplete result and the result page after submitting the search form. Followed test plan, works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Created attachment 42938 [details] [review] [SIGNED OFF] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) The patrons search used by the checkout tab and the autocomplete is not the same as the "search patrons" tab. The main difference is the "contain" vs "start with". So that if you have a patron with a patron with a surname "foo bar" and you search for "foo bar", the autocomplete and the result of a search by the checkout tab will search for "foo%" or "bar%" which won't return the patron you are search for. This patch replaces both autocomplete and checkout tab searches with a "contain" search. The search will be "%foo%" or "%bar%". Note that on big DB, this can cause unexpected results. Test plan: Create a patron with a surname "foo bar" Search for "bar" using the checkout tab. You should see the patron in the autocomplete result and the result page after submitting the search form. Followed test plan, works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar> Created attachment 43044 [details] [review] [PASSED QA] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) The patrons search used by the checkout tab and the autocomplete is not the same as the "search patrons" tab. The main difference is the "contain" vs "start with". So that if you have a patron with a patron with a surname "foo bar" and you search for "foo bar", the autocomplete and the result of a search by the checkout tab will search for "foo%" or "bar%" which won't return the patron you are search for. This patch replaces both autocomplete and checkout tab searches with a "contain" search. The search will be "%foo%" or "%bar%". Note that on big DB, this can cause unexpected results. Test plan: Create a patron with a surname "foo bar" Search for "bar" using the checkout tab. You should see the patron in the autocomplete result and the result page after submitting the search form. Followed test plan, works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> This works as described, but I am concerned about the consequences for big library systems with lots of patron data. The search is very wide now, so it might get really hard to spot the one you have been actually looking for between those that just contain your typed in 3-4 letters. Are there better ways we could achieve this? like "p%" or like " p%" or like "-p%" maybe? Maybe a Syspref in 'Patrons' near 'PatronsPerPage'? -- to enable / disable a 'wider' search for autocomplete -- and/or to define different flavors (start with / contain / ...) -- and/or to give even the possibility to define the fields to search I didn't want to suggest another pref... but it would solve the immediate problem of the behaviour change. *** Bug 15020 has been marked as a duplicate of this bug. *** This is only restoring previous behaviour actually. I'm not sure why we reverted it. But assuming that matching the first firstname/surname is a good relevance algorithm falls short I think. We should definitely consider moving this into fulltext search engines, because after all, using LIKEs is so inefficient... and those tools take care of this things so well... I'm not saying Zebra, we can put it on hold until ES is here, but we should thing ASAP of a better way of doing this. Patch pushed to master. Thanks Jonathan! Pushed to 3.20.x will be in 3.20.5 |