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'
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.
(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
See bug 15252.
(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> )
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.
(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?
(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
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"
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.
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.
Created attachment 49948 [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'
*** Bug 16197 has been marked as a duplicate of this bug. ***
Created attachment 50006 [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>
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>
Pushed to Master - Should be in the May 2016 release! Thanks!
Patch pushed to 3.22.x, will be in 3.22.6
Pushed to 3.22.x, will be in 3.20.11.
*** Bug 15268 has been marked as a duplicate of this bug. ***
Pushed to 3.22.x, will be in 3.22.10
(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.