| Summary: | Patron quick search done on cardnumber even if not inDefaultPatronSearchFields | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Christopher Brannon <cbrannon> |
| Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, kyle.m.hall |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: | Bug 32985: Do not search on cardnumber if not in DefaultPatronSearchFields | ||
|
Description
Christopher Brannon
2023-02-16 19:15:42 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. (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. 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. (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. :) Created attachment 150987 [details] [review] Bug 32985: Do not search on cardnumber if not in DefaultPatronSearchFields 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. (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. (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? |