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

[Bug 43249] New: A duplicate report limit of 1 prevents users from running reports at all
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43249 Bug ID: 43249 Summary: A duplicate report limit of 1 prevents users from running reports at all Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- The code that checks runnign reports checks: $running >= $duplicate_limit, but it appears a report is marked as running during prep_report Additionally Koha::Reports->running returns the reports instances, and not a count - we need to call count on the result -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 42697] New: Home library and current library filters can filter incorrectly
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42697 Bug ID: 42697 Summary: Home library and current library filters can filter incorrectly 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: 1. Create two branches in Koha a. Bearville ( code: BEA ) b. Beachville ( code: BCH ) 2. Find a record and create some items for the BCH branch 3. Now on the record detail page, click Show filters 4. Filter by the Bearville branch ( which should have no items ) for Current library or Home library 5. Notice it filters out everything except the Beachville items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 43787] New: Adding orders from a staged file ( addorderiso2709.pl ) can use gigabytes of memory if there are many funds
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43787 Bug ID: 43787 Summary: Adding orders from a staged file ( addorderiso2709.pl ) can use gigabytes of memory if there are many funds Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The page for adding orders to a basket from a staged file has a fund dropdown for each record, and another for each item when MarcItemFieldsToOrder is used. Each dropdown lists every fund from every budget, inactive ones included, and the template loops that build them are so deeply indented that most of the page is whitespace. With about 1,000 funds ( not difficult for a large system that rolls over funds anually ) and a staged file of 140 records and 287 items, the page is 367 MB, 88% of it whitespace, and the Plack worker that renders it peaks at 4.5 GB of memory. To recreate: 1) Create 1,000 funds in an inactive budget 2) Set MarcItemFieldsToOrder to: homebranch: 952$a holdingbranch: 952$b itype: 952$y 3) Stage a file of 140 records with items from Add to basket > From a new file 4) Click "Add staged files to basket" 5) Note the size of the page and the memory used by the Plack worker -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 43378] New: Wrong hold can be selected when LocalHoldsPriority set to GiveLibraryAndGroup
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43378 Bug ID: 43378 Summary: Wrong hold can be selected when LocalHoldsPriority set to GiveLibraryAndGroup Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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 Target Milestone: --- In C4::Reserves::CheckReserves: if ( !$local_hold_match && $LocalHoldsPriority eq ('GiveLibraryAndGroup') ) { # If there's no match at the library level, check hold groups $local_hold_group_match = Koha::Libraries->find( { branchcode => $local_holds_priority_item_branchcode } )->validate_hold_sibling( { branchcode => $local_holds_priority_patron_branchcode } ); } Then: # See if this item is more important than what we've got so far if ( ( $res->{'priority'} && $res->{'priority'} < $priority ) || $local_hold_match || $local_hold_group_match ) { next Then: last if $local_hold_match || ( ( $LocalHoldsPriority eq 'GiveLibraryGroup' ) && $local_hold_group_match ); That last condition needs to OR "eq 'GiveLibraryAndGroup'" - otherwise we are setting local_hold_group_match, but not exiting the loop, and we pick the local hold group match with the highest priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 43354] New: ILL request table search returns a 500 error
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43354 Bug ID: 43354 Summary: ILL request table search returns a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 33544 Target Milestone: --- The global Search field above the ILL requests table returns a 500 error after the request detail fields were combined into one display column. Steps to reproduce: 1. Enable the ILLModule system preference. 2. Open a patron record. 3. Click "ILL requests history" in the menu on the left. 4. Enter any text in the Search field above the table. Expected result: The table is filtered without an error. Actual result: Koha displays a 500 Internal Server Error and the table does not refresh. Technical note: The combined Request details column has an empty DataTables data source and no related-object search mapping. Global search therefore generates a query for "me." instead of the ILL request extended attributes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33544 [Bug 33544] Squash some ILL fields to alleviate request table overflow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43196] New: PUT requests with a bad request body to biblios endpoint blanks a record
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43196 Bug ID: 43196 Summary: PUT requests with a bad request body to biblios endpoint blanks a record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- TO recreate: 1. Have a record in Koha with good MARC data. In KTD I'm using biblionumber=32 as an example. 2. Do a PUT requested with invalid JSON in it. I did this: curl -u koha:koha -X PUT http://localhost:8081/api/v1/biblios/32 -H "Content-Type: application/marc-in-json" -H "Accept: application/json" -d '{"leader":"00000nam a2200000 a 4500","fields":[{"245":{"ind1":"1","ind2":"0","subfields":[{"a":"STOP HERE ON PURPOSE!!!' 3. The response is 200, success. 4. Now go look at the record in Koha. It is contains nothing in the MARC record now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 23649] New: Elasticsearch offer an option to weight search results by type
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23649 Bug ID: 23649 Summary: Elasticsearch offer an option to weight search results by type 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: nick(a)bywatersolutions.com Some libraries would like to be able to prioritize "books" over "large print" , audios, etc in the search results -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 68

[Bug 43771] New: Override ability for "no renewal before" part of AllowRenewalLimitOverride is not working from patron accounts unless another block exists
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43771 Bug ID: 43771 Summary: Override ability for "no renewal before" part of AllowRenewalLimitOverride is not working from patron accounts unless another block exists Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Target Milestone: --- The starred part of AllowRenewalLimitOverride is not working when overriding renewals from a patron's account unless there is another block such as a hold: "[Allow/Don't allow] staff to manually override renewal blocks and renew a checkout when it would go over the renewal limit or *be premature for the "No renewal before" setting in the circulation policy* or has been scheduled for automatic renewal." However, if there is a second block on the renewal (for instance, another patron's hold on the bib), the override works even when it is still premature. To recreate: Setup: -Set AllowRenewalLimitOverride to [Allow] -Set AllowRenewalOnHoldOverride to [Allow] -Use a staff account with superlibrarian permissions -Set a circ policy to check out an item type for 5 days, 2 renewals allowed, 'No renewal before' set to 1 Part 1: -Find a bib with a single item and no holds, and check it out to a test patron -In the patron's account, click the 'Override renewal restrictions' box - note that no checkbox populates in the patron's checkout table, making it impossible to renew the item early -Go to Circulation > Renew, and input the barcode - note that the renewal is possible via override, which is correct per the system preference (message: [Title/barcode] cannot be renewed before [date].) -Renew the item -Renew again from Circulation (use all available renewals) -Return to the patron's account -Click the 'Override renewal restrictions' box, and note that an override option shows in the patron's checkout table now 0 renewals are remaining (correct per the "when it would go over the renewal limit" part of the system preference) Part 2: -Return the test item -Check the same item out to your test patron -In the patron's account, click the 'Override renewal restrictions' box - no checkbox populates -Go to the bib, and place a hold for another patron -In the original patron's account, click the 'Override renewal restrictions' box - an override option now shows in the patron's checkout table The behavior described above is the same (no override from the patron account unless there's a hold on the bib) when a hold is early due to the 'No automatic renewal before' circ setting. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43313] New: Item's permanent location not shown when item's location is set to CART
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43313 Bug ID: 43313 Summary: Item's permanent location not shown when item's location is set to CART Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- In 25.11 and previous, when items.location and items.permanent_location do not match, Koha shows the permanent_location value followed by the location value in parentheses. This is most often due to the library using UpdateItemLocationOnCheckin to set the location to CART at checkin. In 26.05 and later, the permanent_location value is not displayed. Instead, one is shown only the location in parentheses. So where we would have seen Adult fiction (Shelving cart) We now see (Shelving cart) We should show both values. Inserting a line break between them while we're at it would be nice: Adult fiction (Shelving cart) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 39959] New: Ability to customize the invoice table
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39959 Bug ID: 39959 Summary: Ability to customize the invoice table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org We want to be able to customize the invoice tables we see here https://wcc-rbkc-staff.koha-ptfs.co.uk/cgi-bin/koha/acqui/invoices.pl like we can for the order tables so we can add in the columns we want or hide columns as needed. In particular, we want to be able to add in total columns to this view so when we search for invoices we see the total amounts in the search results to quickly help us work out which invoice is which when we have limited information but know the total amount. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24