Bug 15930 - DataTables patron search defaulting to 'starts_with' and not getting correct parameters to parse multiple word searches
Summary: DataTables patron search defaulting to 'starts_with' and not getting correct ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
: 15268 16197 (view as bug list)
Depends on:
Blocks: 17106
  Show dependency treegraph
 
Reported: 2016-02-28 17:41 UTC by Nick Clemens
Modified: 2017-12-07 22:15 UTC (History)
11 users (show)

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


Attachments
Bug 15930: Make patron searches defaulting on 'contain' (4.28 KB, patch)
2016-04-06 10:36 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15930: Make patron searches defaulting on 'contain' (4.33 KB, patch)
2016-04-06 20:18 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 15930: Make patron searches defaulting on 'contain' (4.39 KB, patch)
2016-04-20 22:27 UTC, Jesse Weaver
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2016-02-28 17:41:10 UTC
So far I know this is affecting:
request.pl
svc/members.search

When two terms are used to search e.g. 'Henry Acevedo' no results are returned

The query in the system is searching for borrower.'surname' LIKE 'Henry Acevedo%'

The searchtype parameter needs to e set to 'contain'
Comment 1 Jonathan Druart 2016-03-01 11:12:59 UTC
I think "start with" has already been the default behavior.
If you want to change that, you can do it using JS or you will need to add a new syspref.
That is not a bug.
Comment 2 Nick Clemens 2016-03-01 11:20:49 UTC
(In reply to Jonathan Druart from comment #1)
> I think "start with" has already been the default behavior.
> That is not a bug.

The other option is to remain with start with, but split terms.  The change from a single result to no results on a full name search 'firstname lastname' is a bug
Comment 3 Jonathan Druart 2016-03-01 12:26:36 UTC
See bug 15252.
Comment 4 Jonathan Druart 2016-03-01 12:29:38 UTC
(On the way, something to fix:
members/member.tt
470               <select name="searchtype" id="searchtype_filter">
471                 <option value='start_with'>Starts with</option>
472                 [% IF searchtype == "contain" %]
473                   <option value="contain" selected="selected">Contains</option>
474                 [% ELSE %]
475                   <option value="contain" selected="selected">Contains</option>
476                 [% END %] 
477               </select>

)
Comment 5 HB-NEKLS 2016-03-03 20:02:06 UTC
This issue is definitely a bug, and a step backward in Koha's search. 

Our system has used Koha for 8 years. And the behavior through 3.18.12 (where our system was before we moved to 3.22.3), was that searching for patrons by both firstname and surname always worked in all the various patron search boxes: holds searching, search patrons, guarantor search, checkout search, etc. 

When we moved to 3.22.3 on Sunday, I could no longer search for patrons using first name and surname on request.pl (holds requests) and guarantor search (The test patron I used was white sox, but we saw this with numerous other patrons). Checkout search with these names worked, as did using search patrons through the patrons page OR moremember.pl. Yesterday, two librarians reported that the search patrons tab on the Koha home page also returned no results. 

Nick has temporarily patched these three instances for us so the system is back to behaving the way it always has behaved. 

There needs to be a more permanent fix for this issue. We can't be the only system where librarians click in these patron search boxes and type in first name and last name.
Comment 6 Jonathan Druart 2016-03-04 08:47:05 UTC
(In reply to Heather Braum from comment #5)
> 
> Nick has temporarily patched these three instances for us so the system is
> back to behaving the way it always has behaved. 

How? Nick, where is the patch? :)

> There needs to be a more permanent fix for this issue. We can't be the only
> system where librarians click in these patron search boxes and type in first
> name and last name.

I understand your POV, but we need to find a solution to satisfy everybody.
If we default to "contains", searches will return too many results.
We could:
1/ add a special case to search on firstname and surname (if start_with)
2/ add a pref to default on contains or start_with
3/ let the libraries who want a different behavior modify the default with some JS code

I like none of these solutions. Anything else to suggest?
Comment 7 Nick Clemens 2016-03-04 13:48:43 UTC
(In reply to Jonathan Druart from comment #6)
> (In reply to Heather Braum from comment #5)
> > 
> > Nick has temporarily patched these three instances 
> How? Nick, where is the patch? :)
It is a quick patch to force contains on the affected pages, I don't think you like that solution :-)

> 2/ add a pref to default on contains or start_with
This is the best option I think so far

> I like none of these solutions. Anything else to suggest?
I think adding an options for phrase searching with qutoes would restore old and allow new behaviour as well.  Terms could be split if not qutoed and used as now if quoted
Comment 8 Kyle M Hall 2016-03-08 18:28:49 UTC
I think using quotes to define names to not split apart makes the most sense.

so a starts_with search for
Kyle Hall
will look for fields starting with "Kyle" and/or fields starting with "Hall"
where a search for
"Kyle Hall"
will look for fields starting with "Kyle Hall"
Comment 9 Ian Bays 2016-04-01 15:02:30 UTC
I suppport what Heather says in comment 5 that it has the appearance of a bug.  If you search for a user with both names from the patron search on the Koha staff home page you get a short list or no results.  If you then do the same search from the Patrons page you get many more results.  If you are worried about getting too many results then you may need to select something different such as "begins with".  We have just installed a couple of new customers with version 3.22.03.000 and they are assuming it will be fixed soon.  I hope this has not stalled.
Comment 10 Blou 2016-04-05 12:25:12 UTC
see also bug 16197

So, this discussion is about "what should be the default behavior of the function", which brings "what is the expected behavior for the users", which could means "The users of previous versions" or "normal internet users used to certain UI behaviors", which are different.

The function works.  It allows for 
- splitting the words and looking for their usages somewhere
- using the word "as-is", including the spaces/commas
It does not allow for
- splitting the words and using each as a start with.  Not a loss, it's mostly useless

My opinion is that it should be resolved in two phases:
1) Add the argument "contains" to each call that need it.  Even if it's all of them, it helps readability of complex functions.
2) Add the possibility of quotes, at which points files like request.pl must NOT do their own s =~ and leave everything to the call.

The 1) is very important to move fast.  Right now it is a bug.  However you define it, this is a regression to the users.  Let's fix that in master before 3.24, and in the next patch for 3.22.

Then let someone develop the quote thing. It's a nice feature and matches users expectations, which are set by big search engines, not by us.
Comment 11 Jonathan Druart 2016-04-06 10:36:47 UTC Comment hidden (obsolete)
Comment 12 Jonathan Druart 2016-04-06 10:37:36 UTC
*** Bug 16197 has been marked as a duplicate of this bug. ***
Comment 13 Nick Clemens 2016-04-06 20:18:48 UTC Comment hidden (obsolete)
Comment 14 Jesse Weaver 2016-04-20 22:27:49 UTC
Created attachment 50483 [details] [review]
Bug 15930: Make patron searches defaulting on 'contain'

The default patron search types has changed from 'contain' to
start_with. Users consider it as a bug.
This patch revert the previous changes to default on 'contain'.

Test plan:
Search for patrons in different places (guarantor, checkout, patron
module, acquisition module, etc.) and confirm that the default is always
'contain'

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Comment 15 Brendan Gallagher 2016-04-22 00:32:18 UTC
Pushed to Master - Should be in the May 2016 release!  Thanks!
Comment 16 Julian Maurice 2016-04-22 10:21:30 UTC
Patch pushed to 3.22.x, will be in 3.22.6
Comment 17 Frédéric Demians 2016-04-27 15:31:12 UTC
Pushed to 3.22.x, will be in 3.20.11.
Comment 18 Barton Chittenden 2016-08-18 18:15:13 UTC
*** Bug 15268 has been marked as a duplicate of this bug. ***
Comment 19 Julian Maurice 2016-08-24 10:52:35 UTC
Pushed to 3.22.x, will be in 3.22.10
Comment 20 Julian Maurice 2016-08-25 07:25:13 UTC
(In reply to Julian Maurice from comment #19)
> Pushed to 3.22.x, will be in 3.22.10

Wrong bug. Please ignore that comment.