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

[Bug 38748] New: Branch name is missing in Return to Home transfer modal
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38748 Bug ID: 38748 Summary: Branch name is missing in Return to Home transfer modal Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 38753] New: Missing table cells breaks OPAC charges table
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38753 Bug ID: 38753 Summary: Missing table cells breaks OPAC charges table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There are a couple of missing instances of the empty '<td></td>' required by DataTables to make the table responsive. The table header/table cell mismatch breaks the DataTable behavior. -- You are receiving this mail because: You are watching all bug changes.

1 17

[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 41120] New: Click on New data provider breaks functionality
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41120 Bug ID: 41120 Summary: Click on New data provider breaks functionality Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk This seems to be a regression bug as in 24.11. this feature is still working. To recreate: - in ERM add a data provider (/cgi-bin/koha/erm/eusage/usage_data_providers) - dummy data should be sufficient - on the new data provider overview click Close on the bottom to return to the data providers list. - open web development tools (F12 on Firefox) - click New data provider and see the error on the console. The reasons seems to be, that the add form gathers an erm_usage_data_provider_id from an older route in from.value.params.erm_usage_data_provider_id -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '26

19 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

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