Bug 14871 - Cannot search for patrons using second surname/firstname
Summary: Cannot search for patrons using second surname/firstname
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
: 15020 (view as bug list)
Depends on:
Reported: 2015-09-22 14:03 UTC by Tomás Cohen Arazi
Modified: 2016-06-21 21:38 UTC (History)
7 users (show)

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

Bug 14871: Extend the patrons search to search like %$term% (checkout tab) (2.02 KB, patch)
2015-09-22 14:10 UTC, Jonathan Druart
Details | Diff | Splinter Review
[Signed-off] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) (2.21 KB, patch)
2015-09-22 17:32 UTC, Marc Véron
Details | Diff | Splinter Review
[SIGNED OFF] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) (2.25 KB, patch)
2015-09-28 17:47 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
[PASSED QA] Bug 14871: Extend the patrons search to search like %$term% (checkout tab) (2.31 KB, patch)
2015-10-02 06:18 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tomás Cohen Arazi 2015-09-22 14:03:32 UTC
If a patron has more than one firstname/surname, the search failas on the checkout tab (and the autocomplete too)

To reproduce:
- Have a patron with two names and two surnames (for example: Tomas ito respectively Cohen Arazi)
- Go to the patron search, search all forms and they work (first name, second name, both, and the same for surnames)
- Go to the Checkout tab, try the same
=> FAIL: it only works when searching for the first one
Comment 1 Jonathan Druart 2015-09-22 14:10:48 UTC Comment hidden (obsolete)
Comment 2 Marc Véron 2015-09-22 17:32:27 UTC Comment hidden (obsolete)
Comment 3 Tomás Cohen Arazi 2015-09-28 17:47:38 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2015-10-02 06:18:20 UTC
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>
Comment 5 Katrin Fischer 2015-10-02 06:21:14 UTC
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?
Comment 6 Marc Véron 2015-10-02 07:44:53 UTC
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
Comment 7 Katrin Fischer 2015-10-02 07:48:24 UTC
I didn't want to suggest another pref... but it would solve the immediate problem of the behaviour change.
Comment 8 Jonathan Druart 2015-10-16 08:55:09 UTC
*** Bug 15020 has been marked as a duplicate of this bug. ***
Comment 9 Tomás Cohen Arazi 2015-10-21 16:51:27 UTC
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.
Comment 10 Tomás Cohen Arazi 2015-10-21 16:51:41 UTC
Patch pushed to master.

Thanks Jonathan!
Comment 11 Chris Cormack 2015-10-23 13:03:10 UTC
Pushed to 3.20.x will be in 3.20.5