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

[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 42534] New: wrapper-staff-tool-plugin.inc interferes with js and includes in template files
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42534 Bug ID: 42534 Summary: wrapper-staff-tool-plugin.inc interferes with js and includes in template files 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 Wrapper changes in Bug 42163 to support the vue changes made in Bug 41367 means you can't use a separate [% MACRO jsincludes BLOCK %] in plugins. Additionally if you're using any includes (such as datatables.inc) they no longer load because the wrapper [% MACRO jsincludes BLOCK %] overrides any inline [% MACRO jsincludes BLOCK %] You can use [% INCLUDE datatables.inc %] outside the wrapper, but most examples have it inside and I fear plugins using the wrapper will break on an update to 26.05. You can also put your <script> after the wrapper for loading it. We could try and make changes to the plugin structure/wrapper to make this work a little smoother. We could add common includes like datatable, calendar, select2, etc into the wrapper, but that seems like a long term maintenance issue. Another way could be to undo the vue change/figure out another way to load the admin menu or otherwise contain it so it's not overriding in page [% MACRO jsincludes BLOCK %] This would be the least disruptive for existing plugins, so is probably the way to go, but I'm not sure there's a good way to handle this. I'm very open to ideas about how to best handle this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[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

[Bug 40383] New: Modernise the EDIFACT Message display modal
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40383 Bug ID: 40383 Summary: Modernise the EDIFACT Message display modal Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 40334 In bugs 40333 and 40334 we split out the modal display of raw edifact messages and allowed them to be display directly on the related basket and invoice pages. This patch aims to modernise their display to allow for both the 'raw' mode as well as a mode modern and easily navigable 'tree' view mode. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40334 [Bug 40334] When EDIFACT is enabled, one should be able view the corresponding EDIFACT QUOTE and ORDER messages on the Koha Basket page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 110