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

[Bug 40070] New: Make appending published date to serial enumeration optional on detail pages
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '26

18 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40070 Bug ID: 40070 Summary: Make appending published date to serial enumeration optional on detail pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Adding the publisheddate after volume info on catalogue/detail and opac-detail is not always an improvement. It might be confusing. Lets add a pref to control it ;) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 23005] New: Specify notice language for vendors
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23005 Bug ID: 23005 Summary: Specify notice language for vendors Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: mbarham(a)birzeit.edu QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- right now, there is no way to specify notices language for vendors. (it is available for Patrons) it will be great if this will be added. regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 24533] New: Improved sorting in checkouts table
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24533 Bug ID: 24533 Summary: Improved sorting in checkouts table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com The sorting in the checkouts table regressed with bug 23493. Before the patch: * Initial table load would group the results by "Today's checkouts" and "Previous checkouts". * Any subsequent column sort would disable the grouping entirely. After the patch: * Initial table load groups the results by "Today's checkouts" and "Previous checkouts". * Any subsequent column sort will sort by that column, but leave the group titles intact. As such, sorting by title for example can end up with multiple "Today's checkouts" header rows which is confusing. I propose that for all column sorts, with the exception of due date, we perform a primary sort on the grouping field followed by a secondary sort on the column in question. This way we maintain the grouping and just sort within the groups. For the due date column sort I propose sorting directly on due date and removing the grouping header rows entirely. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 29562] New: CanItemBeReserved should take patron and item objects as parameters
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29562 Bug ID: 29562 Summary: CanItemBeReserved should take patron and item objects as parameters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CanItemBeReserved takes a borrowernumber and an itemnumber and then fetches the objects to do calculations. Most calls to the routine already have the object, so we should be able to pass them CanBookBeReserved loops on every item, fetching the patron anew each time. Changing the parameters will increase performance. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

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

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '26

16 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4