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

[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| |cassidy.miller@bywatersolut | |ions.com --- Comment #6 from Cassidy <cassidy.miller(a)bywatersolutions.com> --- This is still valid, and it would be really helpful. Library currently asking for it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 ayoung <ayoung(a)oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ayoung(a)oslri.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33886] New: Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Bug ID: 33886 Summary: Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I appreciate a lot of work has gone into swapping from the now-obsolete datepicker to flatpickr. However, when entering a date of birth on the joining form (memberentry.pl), on both the staff intranet and the public OPAC, flatpickr is not intuitive for users. For the staff, having a form cause frustrations when you're welcoming new patrons is not ideal - but at least we can train the staff on flatpickr's quirks. For new patrons trying to join on the OPAC, it's impossible to explain how to use it to them. We are concerned that patrons may choose not to join because of difficulty with the date of birth field. Full explanation: Koha previously used datepicker. It was possible to enter dates using just the keyboard (typing in), or just the mouse (using the datepicker calendar). With flatpickr, you can use the keyboard (typing in) - but if you attempt to use flatpickr as mouse-only, it's extremely long-winded. Flatpickr appears to be designed for mouse+keyboard together, which is unusual - and unexpected for the end user - in a calendar. With datepicker, the mouse workflow was: - Click to open datepicker. Then work from left to right, top to bottom: - Use the dropdown menu to select month. - Use the dropdown menu to select year. - Click on the date to select the date. These steps were all handled by the mouse alone. Using flatpickr, the mouse workflow is: - Click to open flatpickr Note that you cannot work from left to right. This is because flatpickr initialises with today's date. If you have a patron who is born in October but the current month is June, then October doesn't show in the month dropdown (as it's a date in the future). This means you have to start with the year, which is counterintuitive, as it's working right to left. - There is a box to type the year into - meaning that it's not mouse-only. Many average computer users might not even realise that this box can be typed into. Depending on how you use a mouse/keyboard (particularly Tenkey users), typing in can mean lifting your hand from the mouse to use the keyboard and going back again. - The year controls do not display until mouseover, so it's not immediately apparent to all users how the year can be manipulated - especially as this is juxtaposed with the permanently visible month dropdown controls. - When hovering over the year, the arrow controls then appear - and if you're expecting mouse-only input, you may believe you need to use these, rather than typing the year. - The arrow controls only increment +/- 1 year. It's not possible to click and hold to jump +/- 10 years, for example. If you try to use flatpickr as mouse-only and your patron was born in the 1950s, you'll be clicking for a very long time. So the mouse-only workflow ends up being: - Click to open flatpickr - Have to remember to work from right to left - Hover over the year so the arrow controls show - Click 70 times to get back to 1953 - Go right to left to the month drop down to select the month - Then select the date If you choose to type in the year instead, it feels as if it's defeating the object of having a calendar, as you've already typed in 4 digits out of an 8 digit date. Frequent requests have been made to the developer on GitHub for a change to this workflow, but the developer prefers their existing implementation - so a change would need to be a plugin. To alleviate the friction with the year selection, is there a plugin that can be adopted/written/implemented? It doesn't have to be a dropdown plugin; in other calendars, there are different mouse-only methods of handling years, for example: https://element.eleme.cn/#/en-US/component/date-picker (this style is used in Windows). There's some discussion of this on StackOverflow: https://stackoverflow.com/questions/51425067/flatpickr-adding-dropdown-to-c… - including some solutions. And there's a recent (May 2023) dropdown plugin linked from that page: https://gist.github.com/ZachSaucier/ec6f58e49082c27eaae240786bc82997 Please could a plugin be considered? Or a different method of handling year inputs, at least where date of birth is a flatpickr field? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 42402] New: Document OAI-PMH:HarvestEmailReport system preference
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42402 Bug ID: 42402 Summary: Document OAI-PMH:HarvestEmailReport system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Bug 25659 introduced a new system preference: OAI-PMH:HarvestEmailReport. A description of the system preference should be added to the Manual, on the Web services preferences page. It should refer to the Manual section for the OAI harvesting cronjob (and perhaps to the OAI repositories section too). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39860] New: Add a system preference to allow for addtional/custom MARC fields in the record display
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39860 Bug ID: 39860 Summary: Add a system preference to allow for addtional/custom MARC fields in the record display Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could define additional MARC fields in a system preference via Template Toolkit and then have them display on the results/detail pages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 140

[Bug 39256] New: Unable to specify ILL branches like holds branches
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39256 Bug ID: 39256 Summary: Unable to specify ILL branches like holds branches Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com The library branch settings /cgi-bin/koha/admin/branches.pl have a "Pickup location" setting which allows libraries to specify which branches serve as pickup locations for holds. It would be useful to specify whether a branch can be selected in the interlibrary loan location dropdown as well, for analogous reasons (e.g., storage branches which do not fulfill holds nor ILL requests). For our purposes, we could use the same setting to populate the ILL requests branch menu, but it is likely that other libraries may want a branch to serve only holds or holds ILLs for one of any number of reasons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 24977] New: Enable translations for authorised values (POC)
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24977 Bug ID: 24977 Summary: Enable translations for authorised values (POC) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Depends on: 24975 Only a proof of concept to illustrate what's needed to enable translation for a new kind of object. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 [Bug 24975] Refactor database translations -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 24975] New: Refactor database translations
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Bug ID: 24975 Summary: Refactor database translations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr, jonathan.druart(a)bugs.koha-community.org This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. -- You are receiving this mail because: You are watching all bug changes.

1 151

[Bug 42400] New: Include local classification as authority type
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42400 Bug ID: 42400 Summary: Include local classification as authority type Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org Proposing to include local classification data in Authority types We are doing this at present for one of our libraries and could provide the config if desired (if we succeed in making it work...). #Hausnotationen #Systematik #Classification -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #435 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Chloé Zermatten from comment #434) > Is an enhancement, dependency unmet -> not backporting to 25.11 - please do > tell me if that needs changing! I think that's probably the right choice, since this is a fairly big change. I think the QA tools might demand use of 'nonce="[% Koha.CSPNonce | $raw %]"' even in 25.11, but it should be OK to include it in many cases, because it'll just do a "noop" if that CSPNonce function is missing from the template plugin. So backports should be fine to include it even though the underlying mechanism isn't there. -- You are receiving this mail because: You are watching all bug changes.

1 0