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

[Bug 38377] New: Wrong Turkish translation in renewal part
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38377 Bug ID: 38377 Summary: Wrong Turkish translation in renewal part Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: angelic(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com In renewal part there is a missunderstanding. Let me explain with an example. The sentence in English: "2 of 3 renewals remaining" is translated as "2 uzatma hakkınızdan 3 tane kaldı" in Turkish. This is wrong. Right Turkish translation must be like this : "3 uzatma hakkınızdan 2 tane kaldı" This information can be seen in (with a user having renewals): cgi-bin/koha/opac-user.pl page of user. cgi-bin/koha/circ/circulation.pl?borrowernumber=xxxx -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 25673] New: Access logging of borrower's personal information
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '26

19 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25673 Bug ID: 25673 Summary: Access logging of borrower's personal information Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 18081 I don't know if this is directly related to GDPR but at least this seems like a good practice: create a log if a librarian has accessed a Koha page in intranet that contains borrower's personal information. This way the library can make sure by auditing the logs that nobody has for example downloaded all the borrowers' info en masse with screen scraping. Currently this is a bit hard to implement in Koha since borrower's personal info is displayed on many many pages, but to ease this we should think if displaying borrower's real name is necessary or would a cardnumber or borrowernumber be better. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18081 [Bug 18081] [omnibus] GDPR (General Data Protection Regulation) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 40191] New: Design pattern: Redirect user to a view of the record after saving instead of list
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '26

18 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40191 Bug ID: 40191 Summary: Design pattern: Redirect user to a view of the record after saving instead of list Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, michaela.sieber(a)kit.edu, pedro.amorim(a)openfifth.co.uk In the ERM module (and admittedly some other parts of Koha) we redirect the user to the full list of records after a change to a record is saved. This means they need to search again to check the changes and seems counter intuitive. For us it would seem more intuitive to redirect the user to a "view" of the data instead. An example: 1. Add an agreement to the ERM module 2. Confirm: when you save you are redirected to the list of agreements https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements 3. Edit the agreement, make a litle change and save again 4. Confirm: you are redirected to the list of agreements again Our suggestion would be to redirect to the view of the agreement on saving: https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements/1 -- You are receiving this mail because: You are watching all bug changes.

1 60

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