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

[Bug 14413] Map aqorders.order_internalnote in MarcFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14413 Mathieu Saby <mathsabypro(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Comma delimited| |Université Côte d'Azur list of Sponsors| | Sponsorship status|--- |Sponsored -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14413] Map aqorders.order_internalnote in MarcFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14413 --- Comment #7 from Mathieu Saby <mathsabypro(a)gmail.com> --- We are sponsoring that -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40648] New: Add a system preference to configure Koha’s built-in "Cite" feature.
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40648 Bug ID: 40648 Summary: Add a system preference to configure Koha’s built-in "Cite" feature. Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org Currently, Koha’s built-in "Cite" feature provides static citation outputs (APA, Chicago, Harvard, MLA, etc.) without any option to customize which styles appear, the formatting rules applied, or the markup for individual citation components (author, title, date, etc.). There is no system preference to control this behavior, so libraries cannot adjust the citations to meet their local standards or style requirements. Requested Features: - Enable/disable specific citation styles (APA, Chicago, Harvard, MLA, etc.) shown in the “Cite” menu. - Allow customization of output formatting (e.g., italics for titles, full author names, punctuation rules). - Provide markup for individual citation parts (author, title, date, etc.) for CSS styling or integration with other tools. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42392] New: patron_expiration_date on holds is always enforced but never seen or updated
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42392 Bug ID: 42392 Summary: patron_expiration_date on holds is always enforced but never seen or updated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 When a hold is placed via the staff interface or the OPAC, if a "not needed after" date is supplied, that date gets written into both reserves.patron_expiration_date and reserves.expirationdate. The staff interface only shows the user the value in expirationdate. It can be edited or removed entirely. However, changes made here do not change the patron_expiration_date. The cancel_expired_holds cron will cancel a hold with a patron_expiration_date in the past even if expirationdate is null or in the future. This can result in the following scenario: - patron places a hold with an expiration date - patron changes their mind and asks staff to remove the expiration date - hold now shows a blank expiration date in the staff interface and the message "Never expires" on the OPAC - the original expiration date comes, hold is automatically cancelled - patron is sad and confused -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32195] New: Changing a patron category to disallow guarantors should remove existing guarantors
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32195 Bug ID: 32195 Summary: Changing a patron category to disallow guarantors should remove existing guarantors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1: have a patron category where CanBeGuarantee is set to Yes. 2: Create a patron in that category, give them a guarantor 3: edit the patron category to set CanBeGuarantee to No 4: confirm your patron still has a guarantor that shows on the details page, but the guarantor no longer shows on the edit screen 5: this means the guarantor cannot be removed :( I see a few ways to move forward. We could: - make Koha go find and remove relationships right away when a category is updated - provide a script that could be run/cronned to find and delete relationships from the command line -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

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

16 Apr '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 4

[Bug 21528] New: Combine all reserves in a biblio hold-group into a single line entry
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21528 Bug ID: 21528 Summary: Combine all reserves in a biblio hold-group into a single line entry Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Building on the 'reserve next available from a group' functionality implemented in bug 15516 the patches attached to this bug report should combine all the reserves in a hold-group on a biblio into a single line entry on the following interfaces: * reserve/request.pl * Reserves tab in the circ/circulation.pl * members/moremember.pl This will make the reserve queue display manageable and not too overly long -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 15566] Update API to allow to reserve first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15566 Emily Lamancusa (emlam) <emily.lamancusa(a)montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42407] New: Test failure when HoldsLog enabled: t/db_dependent/Koha/Patrons.t
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42407 Bug ID: 42407 Summary: Test failure when HoldsLog enabled: t/db_dependent/Koha/Patrons.t Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: - confirm HoldsLog is set to Don't Log - prove t/db_dependent/Koha/Patrons.t - it passes! - set HoldsLog to Log - prove t/db_dependent/Koha/Patrons.t - it fails :( kohadev-koha@kohadevbox:koha(main)$ prove t/db_dependent/Koha/Patrons.t t/db_dependent/Koha/Patrons.t .. 21/50 # Looks like you planned 6 tests but ran 2. # Failed test 'holds and old_holds' # at t/db_dependent/Koha/Patrons.t line 1310. encountered object '2026-04-18T19:39:47', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at /usr/share/perl5/JSON.pm line 173. # Looks like your test exited with 11 just after 23. t/db_dependent/Koha/Patrons.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 28/50 subtests Test Summary Report ------------------- t/db_dependent/Koha/Patrons.t (Wstat: 2816 (exited 11) Tests: 23 Failed: 1) Failed test: 22 Non-zero exit status: 11 Parse errors: Bad plan. You planned 50 tests but ran 23. Files=1, Tests=23, 7 wallclock secs ( 0.01 usr 0.00 sys + 2.85 cusr 0.60 csys = 3.46 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13823] Item search should include note fields
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13823 Cassidy <cassidy.miller(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwsdonna(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0