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

[Bug 41181] New: SIP2 module should auto-complete (search) patron attribute types for new patron attribute
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41181 Bug ID: 41181 Summary: SIP2 module should auto-complete (search) patron attribute types for new patron attribute Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org When creating/editing an account, under 'SIP response mappings', the "Add new patron attribute" relationship widget should provide a auto-complete (search) for existing patron attribute types for the 'code' input field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42127] New: Inventory tool ( inventory.pl ) does not work well with very large numbers of items
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42127 Bug ID: 42127 Summary: Inventory tool ( inventory.pl ) does not work well with very large numbers of items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org tools/inventory.pl calls GetItemsForInventory with offset => 0 but no size parameter. In C4::Items, the LIMIT clause is conditional: $query .= " LIMIT $offset, $size" if ( $offset and $size ); Because $offset is 0, the LIMIT is never applied. The entire matching result set is loaded into memory via fetchall_arrayref({}). For a library with 500k+ items and broad filters, this easily exhausts available RAM and triggers the OOM killer. The problem is compounded when "Compare barcodes list to inventory" is checked because GetItemsForInventory is called a second time, and the second result set is duplicated into a hash, tripling the in-memory footprint. Test Plan: 1. Have a Koha instance with a large items table (500k+ items) 2. Go to Tools > Inventory 3. Select a branch but leave other filters broad 4. Check "Compare barcodes list to inventory" 5. Upload a barcode file and submit 6. Note the Plack worker's memory consumption spikes, the process may even be killed by the OOM killer I used this query to create 500,000 items: CREATE TEMPORARY TABLE numbers (n INT PRIMARY KEY); INSERT INTO numbers (n) SELECT a.n + b.n*10 + c.n*100 + d.n*1000 + e.n*10000 + f.n*100000 FROM (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) a, (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) b, (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) c, (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) d, (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) e, (SELECT 0 n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) f WHERE a.n + b.n*10 + c.n*100 + d.n*1000 + e.n*10000 + f.n*100000 BETWEEN 1 AND 500000; INSERT INTO items (biblionumber, biblioitemnumber, barcode, homebranch, holdingbranch, itype, notforloan, damaged, itemlost, withdrawn, itemcallnumber, cn_sort, dateaccessioned, location) SELECT b.biblionumber, b.biblioitemnumber, CONCAT('TESTBARCODE', LPAD(numbers.n, 7, '0')), br.branchcode, br.branchcode, (SELECT itemtype FROM itemtypes LIMIT 1), 0, 0, 0, 0, CONCAT('QA ', LPAD(numbers.n, 7, '0')), CONCAT('QA ', LPAD(numbers.n, 7, '0')), CURDATE(), 'GEN' FROM numbers CROSS JOIN (SELECT biblionumber, biblioitemnumber FROM biblioitems LIMIT 1) b CROSS JOIN (SELECT branchcode FROM branches LIMIT 1) br; DROP TEMPORARY TABLE numbers; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 34821] New: Inventory tool optional filters for lost, withdrawn and damaged appear to do nothing
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34821 Bug ID: 34821 Summary: Inventory tool optional filters for lost, withdrawn and damaged appear to do nothing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the inventory tool, the optional not for loan filter will report if a scanned item does not match any of the selected NFL statues. This is not true of of itemlost, withdrawn or damaged. The manual does not specify how these should behave. As far as I can tell, they do nothing. If I set an item to a value and check a different value checkbox, I get no problems reported. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41936] New: Barcode order is different from submitted in inventory report
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 Bug ID: 41936 Summary: Barcode order is different from submitted in inventory report Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To replicate: 1. Run an item search to narrow down on a list of barcodes on a shelf. Be sure to sort the items by call number so the barcodes are ordered as they would appear on the shelf. Add the barcodes to a txt file for upload. 2. Go to the inventory module and upload the barcode file (or paste the barcodes into the barcodes box) 3. Select Compare the barcodes to list. Select the library, shelf location, collection code, add the call number range as needed. 4. Select skip items on loan. 5. Submit. Compare the order of the barcodes on the screen to what was submitted. Notice the barcode order is different. Also notice the problem column states all items are not found in the correct place. I would expect the sort order would match what was submitted. If a different sort order is needed, the table tools gives the option to sort the columns differently. Though, most often, an inventory scans the items on the shelf in a particular order. The report should be ordered in the same way. In my scenario, I submitted the barcodes in this order: 312375 312373 312372 312371 312370 311697 311698 308825 312870 311696 312375 308824 311695 The report returned the barcodes in this order (includes barcodes not scanned because I told it to compare the barcodes to the shelf, skipped barcodes of items checked out): 312836 312838 308824 311695 308825 312870 312837 311696 312377 312839 311698 308830 311697 312376 312840 312374 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 37561] New: Wrong problem in inventory if item has withdrawn status
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37561 Bug ID: 37561 Summary: Wrong problem in inventory if item has withdrawn status Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If an item has a withdrawn status and is nevertheless present on shelf and scanned during the inventory, it will be displayed in the table of the inventory report with this comment in "Problems" column : "Missing (not scanned)" This is wrong, the comment should be something like "Withdrawn status but present on shelf" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41937] New: Items are checked for shelf order in inventory regardless
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41937 Bug ID: 41937 Summary: Items are checked for shelf order in inventory regardless Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The inventory tool has an option to "Check barcodes list for items shelved out of order:" If this option is selected, I would expect the inventory report to include a comment in the Problems column for items that are "Found in the wrong place" If this option is NOT selected, the inventory goes ahead and tells me if items are in the incorrect place, regardless. It's not clear what selecting the option does. If I do not select the option, I would not expect to see "found in wrong place" problems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41046] New: BOOKING_CANCELLATION authorized value category is missing a description
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41046 Bug ID: 41046 Summary: BOOKING_CANCELLATION authorized value category is missing a description Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When going to Administration > Authorized values, the Description column for the BOOKING_CANCELLATION authorized value category is empty. To be consistent with HOLD_CANCELLATION and other default cancellation-related categories, it should have something like: "Reasons why a booking might have been cancelled". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42356] New: New yarn build warning: if() syntax is deprecated
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42356 Bug ID: 42356 Summary: New yarn build warning: if() syntax is deprecated 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: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 38426 Deprecation Warning [if-function]: The Sass if() syntax is deprecated in favor of the modern CSS syntax. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38426 [Bug 38426] Node.js v18 EOL around 25.05 release time -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 36975] New: Allow MarcModificationTemplates to change the record source for a batch of records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36975 Bug ID: 36975 Summary: Allow MarcModificationTemplates to change the record source for a batch of records 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: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice to be able to set the record source for a whole set of records (from a search result or a report). Best way to do it seems to permit the "BatchRecordModification Tool" to change the record source value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 36884] New: Make it possible to use the record_source as a criteria for a search
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36884 Bug ID: 36884 Summary: Make it possible to use the record_source as a criteria for a search 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: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I'm not sure what would be the more efficient, using SQL and the ORM or add some ES index, but we need to have a way to find all records which belongs to a record_source. It would as well be nice to be able to do a batch edit to change the source of a record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11