Bug 32985 - Patron quick search done on cardnumber even if not inDefaultPatronSearchFields
Summary: Patron quick search done on cardnumber even if not inDefaultPatronSearchFields
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-16 19:15 UTC by Christopher Brannon
Modified: 2023-05-10 15:59 UTC (History)
3 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 32985: Do not search on cardnumber if not in DefaultPatronSearchFields (2.16 KB, patch)
2023-05-10 12:27 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2023-02-16 19:15:42 UTC
So, we've had no problem searching for patrons in Koha via cardnumber in general, even though we didn't list cardnumber in DefaultPatronSearchFields.  This may be because we also use the cardnumber as the username.  BUT, we don't define the username as one of the searchable fields in DefaultPatronSearchFields.  So, Koha is finding either the cardnumber or the username without it being in this preference.

We figured this out because we could not search for guarantors by cardnumber until we put this field in DefaultPatronSearchFields.  Now it works.  So, guarantor search is adhering to this setting, but the rest of Koha is not.
Comment 1 Katrin Fischer 2023-02-17 18:36:53 UTC
Have you tested with another field?

I think there is a shortcut on the cardnumber, so you can't probably exclude it from normal search. If there is a direct match on cardnumber, we open the record without displaying the results..

For the guarantor search there is no redirect.. so I guess it does not do that kind of check.
Comment 2 Christopher Brannon 2023-02-17 22:57:01 UTC
(In reply to Katrin Fischer from comment #1)
> Have you tested with another field?
> 
> I think there is a shortcut on the cardnumber, so you can't probably exclude
> it from normal search. If there is a direct match on cardnumber, we open the
> record without displaying the results..
> 
> For the guarantor search there is no redirect.. so I guess it does not do
> that kind of check.

Yes, as I have said, I can search by name.

So, if there is no consistency between this search and the regular patron search, to me that is a bug.  This needs to be consistent.
Comment 3 Katrin Fischer 2023-02-18 09:35:29 UTC
I mean have you tried searching for a field that is not the cardnumber and not included in the pref.

My impression is that we might only have an exception for cardnumber in patron search as we do this as a first step to directly open the record for an exact match.
Comment 4 Christopher Brannon 2023-02-21 18:05:42 UTC
(In reply to Katrin Fischer from comment #3)
> I mean have you tried searching for a field that is not the cardnumber and
> not included in the pref.
> 
> My impression is that we might only have an exception for cardnumber in
> patron search as we do this as a first step to directly open the record for
> an exact match.

I understand.  I have, and regular patron search works as expected.  I've added fields we've needed to search by and the preference works.  That exception you mention is understandable, but misleading because it does not work for all patron searching, as in guarantor searching.  It needs to be consistent.

If we are going to have the cardnumber searchable regardless of what is in DefaultPatronSearchFields, it should be mentioned on the preference, and work EVERYWHERE, not just some places.  Otherwise we have oddballs like me trying to figure out what is wrong and filing bugs.  :)
Comment 5 Jonathan Druart 2023-05-10 12:27:42 UTC
Created attachment 150987 [details] [review]
Bug 32985: Do not search on cardnumber if not in DefaultPatronSearchFields
Comment 6 Jonathan Druart 2023-05-10 12:28:24 UTC
This patch should fix the problem you are describing, but not sure it's something we want. This behaviour has been around for years now.

Lowering priority.
Comment 7 Christopher Brannon 2023-05-10 14:09:10 UTC
(In reply to Jonathan Druart from comment #6)
> This patch should fix the problem you are describing, but not sure it's
> something we want. This behaviour has been around for years now.
> 
> Lowering priority.

If it is not something you want, I'm not sure why you are providing it.  A couple of options were presented.

A) Make it consistent with how the preference works with everything else defined or not defined.

B) Make it the exception, and list it as so in the description.

Either way, it just needs to be consistent.  There is no sane reason for having it work one way in some places, and another in other places.  Let's just decide on a a consistent way of making this function, and help everyone to understand how it functions.  That is all I ask.
Comment 8 Jonathan Druart 2023-05-10 15:59:56 UTC
(In reply to Christopher Brannon from comment #7)
> (In reply to Jonathan Druart from comment #6)
> > This patch should fix the problem you are describing, but not sure it's
> > something we want. This behaviour has been around for years now.
> > 
> > Lowering priority.
> 
> If it is not something you want, I'm not sure why you are providing it.  A
> couple of options were presented.
> 
> A) Make it consistent with how the preference works with everything else
> defined or not defined.

This is what the patch does. I've provided it for discussion. Did you try it? Does it fit your needs?