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

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Jake Deery <jake.deery(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194813|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42401] New: Problem with translation of "More"
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42401 Bug ID: 42401 Summary: Problem with translation of "More" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com On a Swedish site we noticed that the word "More" (class="nav-link-text") in the main menu in the staff client was not translated. It comes from this code in the template (koha-tmpl/intranet-tmpl/prog/en/includes/header.inc): [% tp("More menu options", "More") | html %] It looks like the problem is that the single word "More" only occurs once in the translated files: $ sudo grep '"More"' /usr/share/koha/misc/translator/po/sv-SE* /usr/share/koha/misc/translator/po/sv-SE-staff-prog.po:msgid "More" If I add this to /usr/share/koha/misc/translator/po/sv-SE-messages.po, update the translation and restart plack it fixes the "More" in the main menu: #: koha-tmpl/intranet-tmpl/prog/en/includes/header.inc:47 msgctxt "More menu options" msgid "More" msgstr "Mer" This: $ sudo grep -rn '"More"' /usr/share/koha/intranet/htdocs/ shows there is at least one more use of "More", with a different context: [% tp("Show more information", "More") | html %] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40510] New: Separate translation of More dropdown to it's own string
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40510 Bug ID: 40510 Summary: Separate translation of More dropdown to it's own string Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org In version 24.xx the More dropdown in the main header had it's own string in translations and we had translated it to "Muita toimintoja" (Other functions). In version 25.xx it has been combined with other "More" terms which is translated as "Lisätietoja" (More information). This translation does not fit with the dropdown but is otherwise ok. We would like to separate the header's More string from the others so that we can continue to make a different kind of translation for it. The More from header is now part of this string: https://translate.koha-community.org/translate/koha/main/staff-prog/fi/?che… -- You are receiving this mail because: You are watching all bug changes.

1 17

[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