| Summary: | Have a way to add optional fields to patron search that won't be included in a standard search | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Lucas Gass (lukeg) <lucas> |
| Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | gmcharlt, hebah, kyle, saiful |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Lucas Gass (lukeg)
2025-02-26 17:50:59 UTC
Another use-case supporting this as an enhancement: Many libraries use unique extended patron attributes to store alternate IDs (e.g., HID/NFC card numbers). These attributes are searchable only directly and not in Standard search. Historically, staff could identify a patron by scanning the HID card directly in the checkout box. After the introduction of DefaultPatronSearchFields, this is no longer possible. Allowing extended patron attributes to be selected in DefaultPatronSearchFields would restore this workflow and cover this use-case. (In reply to Saiful Amin from comment #1) > > Allowing extended patron attributes to be selected in > DefaultPatronSearchFields would restore this workflow and cover this > use-case. I probably misunderstood the original intent of this bug. Perhaps I will create a new one for this. |