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

[Bug 32928] New: Filters missing in SQL builder on Orders::filter_by_active
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32928 Bug ID: 32928 Summary: Filters missing in SQL builder on Orders::filter_by_active Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since version 21.xx.xx there has been a change in the way to retrieve the data of the orders to receive. The table is built from a call to the API and then the data can be filtered. Bug_20212 has integrated this change. This is a good thing but two filters are missing on the query construction in the Koha::Acquisition::Orders::filter_by_active function Here is the query in version 20.11 : <pre> SELECT aqbasket.basketno, borrowers.surname, borrowers.firstname, biblio.*, biblioitems.isbn, biblioitems.biblioitemnumber, biblioitems.publishercode, biblioitems.publicationyear, aqbasket.authorisedby, aqbasket.booksellerid, aqbasket.closedate, aqbasket.creationdate, aqbasket.basketname, aqbasketgroups.id as basketgroupid, aqbasketgroups.name as basketgroupname, aqorders.* FROM aqorders LEFT JOIN aqbasket ON aqorders.basketno = aqbasket.basketno LEFT JOIN aqbasketgroups ON aqbasket.basketgroupid = aqbasketgroups.id LEFT JOIN borrowers ON aqbasket.authorisedby=borrowers.borrowernumber LEFT JOIN biblio ON aqorders.biblionumber=biblio.biblionumber LEFT JOIN biblioitems ON biblioitems.biblionumber=biblio.biblionumber WHERE (datecancellationprinted is NULL) AND ( ( aqbasket.is_standing AND aqorders.orderstatus IN ( "new", "ordered", "partial" ) ) OR ( ( quantity > quantityreceived OR quantityreceived is NULL ) AND aqorders.orderstatus IN ( "ordered", "partial" ) ) ) AND aqbasket.booksellerid = ? ORDER BY aqbasket.basketno'; </pre> The condition "datecancellationprinted is NULL" is missing as well as the quantity control to display the results only if there are still quantities to receive. And so the result on the same database between the different versions can be very different! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 41228] New: Batch item modification - deleting individual subfield doesn't work
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41228 Bug ID: 41228 Summary: Batch item modification - deleting individual subfield doesn't work Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the Batch item modification tool, deleting the content from individual item subfields doesn't work The following steps were executed: - Search for items that are populated with content from an individual 952 subfield (i. e. 952 $E) in the item search (an item search field for that subfield has been created, connected with an Authorized Value) - Mark a few or all items from the result list - Send them to Batch operations - Batch item modification - Check the checkbox on the right of the individual subfield - Save - The job afterwards says, "No items modified" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41880] New: Logs for moved holds don't indicate original bib number/item number
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41880 Bug ID: 41880 Summary: Logs for moved holds don't indicate original bib number/item number Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a hold is moved from bib A to bib B (or from item A to item B), and no change was made to the hold before the move, there is no way to identify the bib or item number of the original hold. To replicate: -Place a hold on bib A (or item A) -View it in Tools > Logs using the reserve_id. As is standard, no details other than the reserve_id show in the Info column. -Move the hold to bib B (or item B) -Run the holds log again for the reserve_id. Note that an entry is generated for the move, but only the bib number (or item number) it was *moved to* shows. There is no way to know what bib or item the hold was moved *from*. If a change is made to a hold before it's moved, staff will be able to see the original bib number/item number in logs. But there are likely to be many cases where the first change made to a hold is moving it to a new bib/item, which means that the original bib number/item number will be untraceable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 41883] New: Modifications using batch hold modification tool aren't logged
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41883 Bug ID: 41883 Summary: Modifications using batch hold modification tool aren't logged Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Changes made via the batch hold modification tool that are logged when made to holds individually from the bib are not logged when using the tool. To replicate: -Place a hold -Run the Holds log using the hold's reserve_id. There will be a single entry for the hold's creation. -Find the hold using the batch hold modification tool, and update its pickup location -Run the Holds log for that hold, and note that no entry has been generated for the changed pickup location -From the bib's Holds tab, update the same hold's pickup location -Run the Holds log again for that hold, and note that an entry was generated for the pickup location change when it was updated from the bib The same issue applies for updating expiration dates and for suspending/unsuspending, all of which do generate log entries when performed on individual holds from the bib. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41801] New: FixPriority recursive calls for lowestPriority holds can be removed
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41801 Bug ID: 41801 Summary: FixPriority recursive calls for lowestPriority holds can be removed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Currently, C4::Reserves->FixPriority adjusts the holds not marked for lowestPriority, then recursively calls itself for each lowestPriority hold, touching all the non-found holds on the record each time. This can be removed as we can simply sort the lowestPriority holds to the bottom when getting the list of holds to adjust -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42163] New: wrapper-staff-tool-plugin.inc no longer loads the admin menu
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42163 Bug ID: 42163 Summary: wrapper-staff-tool-plugin.inc no longer loads the admin menu Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 41367 broke the wrapper for the plugin and it no longer loads on plugins when using the wrapper. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 41367] New: Staff user interface - no sidebar menu when on record sources pages
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41367 Bug ID: 41367 Summary: Staff user interface - no sidebar menu when on record sources pages 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are no sidebar menu items when you are on record sources pages: 1. Go to Administration > Catalog > Record sources. 2. Note that there are no standard sidebar menu items on the left-hand side. 3. Add a new record source. 4. Note the same as step 2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 41343] New: Overdue report is too intensive on systems with many overdues
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41343 Bug ID: 41343 Summary: Overdue report is too intensive on systems with many overdues Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 41432] New: Add prefetch to improve performance of holds page
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41432 Bug ID: 41432 Summary: Add prefetch to improve performance of holds page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com To view the issue: 1 - Add a bunch of holds to a record https://github.com/kidclamp/handy-koha-script/blob/main/randhold.pl 2 - Enable profiling: https://wiki.koha-community.org/wiki/Profiling_with_Devel::NYTProf#NYTProf_… 3 - Browse to the record and load the holds table 4 - View the flame graph for the request like instructions in #2 5 - Note that Koha::Hold->borrower and Koha::Hold->item take a lot of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 40777] New: 500 Error: Something went wrong when loading the table Should Exit Cleanly
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40777 Bug ID: 40777 Summary: 500 Error: Something went wrong when loading the table Should Exit Cleanly Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It's possible this is related to/a duplicate of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40762 but I am not certain. In Koha 24.05 and 24.11, in the staff interface, if a bib with an item without a 952$a and 952$b is imported, when the staff member then goes to the bib record they receive a modal pop-up stating "Something went wrong when loading the table. 500: error". If they click OK on that message, a processing box sits on the screen (you can see the bib loaded behind it) and spins. The console log shows: datatables_24.1107000.js: 408 DataTables warning: table id=holdings_table - Ajax error. For more information about this error, please see https://datatables.net/tn/7 The "processing" box is not modal and it is possible to click on Edit, Manage items, and then edit the problem item to add the missing Home and Current libraries and resolve the cause of the error. This behavior does not occur in 23.11. While, of course, the item needs the Home and Current library, the error alert is a change in expected behavior from staff member perspective. A cleaner exit with a more informative message than a 500 error seems preferable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72