July 2026 - Koha-bugs - lists.koha-community.org

[Bug 43106] New: Patrons used for SIP clients should have separate permission
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43106 Bug ID: 43106 Summary: Patrons used for SIP clients should have separate permission Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I note that there's only 1 permission currently used for SIP clients and that's the "circulate" permission as per "api_auth" called in "login_core" in C4::SIP;:Sip::MsgType. I think we could keep it backwards compatible, but it would be better I think to have an explicit "sip_client" permission, since it seems very very common that people over-permission their SIP accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40802] New: cleanup_database is broken with ChildNeedsGuarantor
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40802 Bug ID: 40802 Summary: cleanup_database is broken with ChildNeedsGuarantor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Steps to reproduce : 1 - Have a child expired patron expired for more than the content of LockExpiredDelay syspref 2 - Set syspref to "childneedsguarantor" 3 - Run /home/koha/src/misc/cronjobs/cleanup_database.pl You will get an uncaught error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42728] New: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42728 Bug ID: 42728 Summary: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce. 1 - Go to /cgi-bin/koha/members/moremember.pl?borrowernumber=37 and make sure it is a Kid without guarantor. 2 - Enable ChildNeedsGuarantor 3 - Run ./misc/cronjobs/cleanup_database.pl -v --confirm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35369] New: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35369 Bug ID: 35369 Summary: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have a syspref / sip configuration option to remove or customize this message without having to use regex on the AF field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 41922] New: Better prevent double submit of checkout form
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41922 Bug ID: 41922 Summary: Better prevent double submit of checkout form Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When checking out an item to a patron in the staff interface, we have Javascript protecting the barcode field from re-submitting the form while Koha is still processing the checkout. However, we don't have anything preventing the submit button from double-submitting the form. We should protect against all possible methods of double-submitting, not just the barcode input. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 36165] New: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36165 Bug ID: 36165 Summary: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 36164 We should take inspiration from existing landing pages, Cataloging, Circulation, Reports, and Administration all come to mind. It would be great to have all of these manifest in a more consistent form. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36164 [Bug 36164] Bring more consistency to our module landing pages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 40082] New: PatronDuplicateMatchingAddFields isn't respected in the OPAC or the API
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40082 Bug ID: 40082 Summary: PatronDuplicateMatchingAddFields isn't respected in the OPAC or the API Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There is a syspref for checking new patrons for duplicates that is only implemented in the staff interface - it should also be respected when adding a patron via the API or the OPAC -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 29720] New: Allow per-user customization of table settings
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29720 Bug ID: 29720 Summary: Allow per-user customization of table settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Table settings are currently global. Per-user customization would be great! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 42403] New: We should drop Flatpickr in preference for native datepickers
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42403 Bug ID: 42403 Summary: We should drop Flatpickr in preference for native datepickers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: blawlor(a)clamsnet.org, daniel.jones(a)cheshiresharedservices.gov.uk, david(a)davidnind.com, dcook(a)prosentient.com.au, fiona.borthwick(a)openfifth.co.uk, gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, lucas(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org, sally.healey(a)cheshiresharedservices.gov.uk, testopia(a)bugs.koha-community.org Depends on: 33886 Blocks: 23003 Flatpickr doesn't seem to go down well in accessibility circles and we keep getting general complaints about it.. at the same time native date inputs have really come on in recent years... It's time to rethink our datepicking.. with that in mind I did the following review. Here's my analysis of what flatpickr provides and what we'd lose. 1. What native HTML inputs CAN replace (covers ~80% of uses) =========================================================== * Date/Time/Combined pickers: Use native type="date", "time", or "datetime-local". * Constraints: Use "min" and "max" attributes. * Masking: Not needed; native inputs handle format natively. * Date format: Uses browser locale (better for a11y). * JS Logic: Simple tasks like "set-to-today" use trivial valueAsDate JS. 2. What needs custom JS but is straightforward (~10%) =========================================================== Feature | Replacement ----------------------------------|-------------------------------------------- Date range linking (data-date_to) | ~20 lines vanilla JS 'change' listener fp_incr() calls | Native new Date(d.setDate(...)) flatpickr.parseDate() | Native new Date() + format-aware parsing .setDate() / .selectedDates | Direct .value / .valueAsDate access ._flatpickr instance access | Direct DOM .value access Validation (validate_date) | Native 'invalid' event for custom messages 3. What we'd genuinely LOSE (~10%, but the hard 10%) =========================================================== * Arbitrary date enable/disable: Native inputs only support contiguous ranges. This is a dealbreaker for: - Bookings module (disabling dates based on availability). - Future-inclusive editing (selecting original past date OR future dates). - Holidays module (marking specific closed dates). * Shortcut buttons: No native equivalent for Yesterday/Today/Tomorrow buttons. * Period/range selection: Native inputs don't support range-in-a-single-field; would require two inputs. * Vue wrappers: Need new components for ERM/Acquisitions. * Format consistency: Native follows browser locale, not the Koha 'dateformat' system preference. 4. Verdict =========================================================== Flatpickr could be removed for the majority of inputs (filters, patron forms, etc.). However, it cannot be removed from the Bookings or Holidays modules without a replacement widget that supports disabling arbitrary dates. Proposed Path: 1. Phase 1: Replace simple inputs with native. 2. Phase 2: Build thin abstraction for range linking. 3. Phase 3: Keep Flatpickr for complex views or evaluate an accessible alternative. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] [OMNIBUS] Accessibility improvements https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 [Bug 33886] Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42490] New: Allow configuration of LocalHoldsPriority to apply only at checkin, not when building holds queue
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42490 Bug ID: 42490 Summary: Allow configuration of LocalHoldsPriority to apply only at checkin, not when building holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Some libraries would like LocalHoldsPriority to impact only the choice of which hold should be filled when an on-loan item is returned, without impacting how the holds queue is built. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48