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) => SUCCSES - Go to the Checkout tab, try the same => FAIL: it only works when searching for the first one
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