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

[Bug 34879] New: ./catalogue/getitem-ajax.pl appears to be unused
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34879 Bug ID: 34879 Summary: ./catalogue/getitem-ajax.pl appears to be unused Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I can't find any reference to ./catalogue/getitem-ajax.pl in Koha, so I think it could probably be removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41689] New: "Staff note" and "OPAC" message types in patron files untranslatable
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41689 Bug ID: 41689 Summary: "Staff note" and "OPAC" message types in patron files untranslatable 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com The message types were added by bug 40367, but they are not translatable. To recreate: 1. Go to a patron account > Add message 2. Add a message with "Staff - Internal note" 3. Add a second message with "OPAC - [Name]" 4. Add a language to your Koha gulp po:update --lang fr-CA ./misc/translator/translate install fr-CA Add the language in StaffInterfaceLanguages 5. Switch to the new language 6. Go to the patron's account --> Staff note is in english --> OPAC is in English (this is normal in fr-CA because we still call it OPAC even if it's an english term, but could be different in another language) 7. Check the translation files cd misc/translator/po/ git grep "Staff notes" fr-CA* --> There is nothing from patron-messages.inc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41752] New: Guarantor first name and guarantor surname mislabeled in system preferences
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41752 Bug ID: 41752 Summary: Guarantor first name and guarantor surname mislabeled in system preferences Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com In the sysprefs BorrowerMandatoryField, BorrowerUnwantedField and the OPAC variations of each, the fields contactfirstname and contactname are labeled as: Alternate contact: First name (contactfirstname) Alternate contact: Surname (contactname) But the patron edit screen they are labeled as "Guarantor first name" and "Guarantor surname." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 41458] New: SIP passes UID instead of GID to Net::Server causing error
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41458 Bug ID: 41458 Summary: SIP passes UID instead of GID to Net::Server causing error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36386 When starting SIP, Koha passes an incorrect value to the Net::Server "group" parameter. The code passes the effective UID ($>) instead of a group ID. On systems where UID and GID differ, Net::Server attempts to switch to a non-permitted group and logs an error. SIP starts with this error and continues running. To test: 1. Enter KTD shell. 2. Run: sudo koha-sip --restart kohadev 3. Check SIP logs and observe: [ERROR] [undef]@[undef]: Couldn't become gid "501": Operation not permitted C4::SIP::Trapper::__ANON__ /kohadevbox/koha/C4/SIP/Trapper.pm (70) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36386 [Bug 36386] Prevent Net::Server warn about User Not Defined from SIPServer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 41588] New: Link from 856$u breaks with leading or trailing spaces
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41588 Bug ID: 41588 Summary: Link from 856$u breaks with leading or trailing spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Leading or trailing spaces in the 856$u add "%20" to the url, breaking it. To recreate: - add 856$u "www.cheese.com" to a record; it works! - add 856$u " www.cheese.com" to a record; it doesn't work - add 856$u "www.cheese.com " to a record; it doesn't work We've got a syspref to strip those characters out when editing a record, but we may as well also deal with spaces in the XSLT for old records and/or libraries that haven't enabled the syspref. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[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 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 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 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 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