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

[Bug 37088] New: Make library groups accessible as runtime parameter category in reports
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37088 Bug ID: 37088 Summary: Make library groups accessible as runtime parameter category in reports Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org It would be helpful if you could use library groups as runtime parameter in the saved reports. There is already runtime parameter for libraries but many times we need to use a certain group of libraries and we have to "pick" them manually when a library group would be much easier to use. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11591] runtime parameter for library groups
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11591 Brendan Lawlor <blawlor(a)clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anneli.osterman@koha-suomi. | |fi --- Comment #5 from Brendan Lawlor <blawlor(a)clamsnet.org> --- *** Bug 37088 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34459] New: Log in MARC record if the record was brought in via z39.50
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34459 Bug ID: 34459 Summary: Log in MARC record if the record was brought in via z39.50 Change sponsored?: --- Product: Koha Version: unspecified 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 For some libraries, it would be helpful to be able to report on and find what records are being brought in via a z39.50 search. If a value or indication could exist in the record, this would be easy for libraries to identify and find. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 40916] New: Cannot edit a list to have a sortfield value of anything other than publicationyear
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40916 Bug ID: 40916 Summary: Cannot edit a list to have a sortfield value of anything other than publicationyear Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl TO recreate: 1. Create a list 2. Sort this list by: title 3. Save 4. Edit the list, changing the the "Sort this list by:" to copyrightdate 5. Try to edit it again to any other type of sort. Save 6. Look again, it is reverted to copyrightdate -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 37434] New: Lists are incorrectly sorted in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37434 Bug ID: 37434 Summary: Lists are incorrectly sorted in UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In UNIMARC, when creating a list using sort by copyrightdate, it sorts using the MARC21 field "copyrightdate", which is not existing in UNIMARC. Note: the inventory search uses the field publicationyear to sort, which is the correct field to use here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 40655] New: Transport cost matrix doesn't save changes
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40655 Bug ID: 40655 Summary: Transport cost matrix doesn't save changes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When editing transport-cost-matrix, it will save the numbers but not if you've enabled transfers. It also doesn't reflect disabled/enabled correctly from the database, so if you go in and make changes it re-disables them. To recreate: 1. Turn on the UseTransportCostMatrix system preference 2. Got to Administration/transport cost matrix 3. Edit a number of boxes to add numbers and uncheck the 'disabled' box 4. save 5. Observe that all (or most?) of the boxes are still disabled. 6. Run a report: select * from transport_cost where cost !='0.00' 7. Observe that they are disabled. 8. in koha-mysql: update transport_cost set disable_transfer = 0 where cost !=0.00; 9. Repeat step 6, they should have 0 instead of 1 for disable_transfer 10. Navigate to the transport cost matrix (don't refresh the page!) 11. Observe that the boxes are still disabled 12. Save (no changes needed) 13. Repeat step 6 14. Observe they are once again marked as disable_transfer 1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 39302] New: Checkin disappear from checkin list if transfer modal is triggered
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39302 Bug ID: 39302 Summary: Checkin disappear from checkin list if transfer modal is triggered Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There is a flaw in the logic of the checkin code: we keep 20 (default value for numReturnedItemsToShow) checkins in the table, but there can be shift in the "counter" logic when the transfer modal is triggered. There are actually several other problems in the logic of this controller but we are going to try and focus on only this one. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 37222] New: Standardize markup for sidebar menus
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37222 Bug ID: 37222 Summary: Standardize markup for sidebar menus Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org We've got a couple of different ways we're marking up sidebar menus, and we're limiting ourselves by tying the style to an ID. There are a few cases where we want to include more than one menu in the sidebar and we shouldn't have to update CSS just to make them consistent. I'm proposing: <div id="circ-menu" class="sidebar_menu"> <ul> ... </ul> </div> -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 41159] New: A plugin with an invalid date_updated causes the whole plugin page to crash
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41159 Bug ID: 41159 Summary: A plugin with an invalid date_updated causes the whole plugin page to crash Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org Koha expects (in koha-tmpl/intranet-tmpl/prog/en/modules/plugins/plugins-home.tt) for the plugin metadata to be a valid date (parsed using dt_from_string in Koha::DateUtils). This isn't ever checked beforehand though, so installing a plugin with a broken date (I built https://codeberg.org/tadzik/KohaBreaker/releases/tag/0.1-broken-date for demonstration) results in the following exception being thrown: Template process failed: undef error - The given date (2025-10-310) does not match the date format (iso) I'm not sure what would be the right time to verify the metadata structure – install time sounds like a good time? At the same time it'd be nice if the error wasn't this catastrophic, so that if such plugin were to be installed one way or another, it shouldn't blow up the whole plugins page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41157] New: Inconsistency between patron JS display and patron-title.inc
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41157 Bug ID: 41157 Summary: Inconsistency between patron JS display and patron-title.inc 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 30568 comment 39: I would like to note that we have currently an interesting tree in the queue (under bug 40995) which improve the JS counterpart (patron-format). The inc file is moved to a standalone JS file, Cypress tests are added, and more places are using it. I do understand that we want to make the display more flexible, but here we need to keep the 2 versions in sync: they have the same purpose. However we don't include html tags in the JS function yet (why?) I don't want to block it, but keep in mind that you are not affecting all the occurrences, which introduces more inconsistencies IMO. A better solution seems to have a new syspref to let libraries provide their desire format, you could pick patron's fields, and add punctuation. The both (tt and js) versions of the code will use it. Maybe for a follow-up bug? Hope that makes sense! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0