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

[Bug 40101] New: Add `Koha::Patron->can_place_holds`
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40101 Bug ID: 40101 Summary: Add `Koha::Patron->can_place_holds` Change sponsored?: --- Product: Koha Version: Main Hardware: PC OS: Mac OS Status: NEW Severity: enhancement Priority: P1 - high Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com Some checks for patron's ability to place holds are baked in * controllers (e.g. opac-reserve.pl, request.pl) * templates (e.g. opac-reserve.tt, request.tt) We should move that logic into a reusable sub, covered with tests. My initial motivation is bug 39657 so we use this on the API, but it is a good opportunity to start cleaning up the codebase in the area as well. -- You are receiving this mail because: You are the assignee for the bug.

1 30

[Bug 36094] New: svc/authentication not used
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36094 Bug ID: 36094 Summary: svc/authentication not used Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Looks like we can remove it. -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 42504] New: Remove totalissues from stored MARC, embed at index time
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42504 Bug ID: 42504 Summary: Remove totalissues from stored MARC, embed at index time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org ## Problem update_totalissues.pl can run for 4+ hours on large installations. The root cause is that totalissues is stored in the MARC record (942$0), requiring the full ModBiblio pipeline per biblio: MARC XML deserialization, field update, serialization, TransformMarcToKoha, DB updates, search engine reindexing, cataloguing log entries, plugin hooks, OAI sets updates. The existing UpdateTotalIssuesOnCirc syspref provides real-time updates on checkout but is disabled by default because it triggers this same expensive ModBiblio pipeline on every checkout. Bug 36474 improved things by skipping unchanged records, but every changed record still pays the full cost. ## Proposal Stop storing totalissues in the MARC record. Instead: 1. UpdateTotalIssues becomes a lightweight DB-only operation: just UPDATE biblioitems SET totalissues = ? WHERE biblionumber = ? plus queue a search index update. No MARC parsing, no ModBiblio. 2. Inject 942$0 at index time via Koha::Biblio::metadata_record: Add an embed_total_issues parameter (following the existing embed_items pattern). Both search engine indexers call metadata_record to get the MARC before indexing. The value gets injected from biblioitems.totalissues on the fly, just like items are embedded today. The stored MARC in biblio_metadata stays clean. Both the ES indexer (_get_record) and Zebra's rebuild_zebra.pl -d (which already pre-processes records before sending to Zebra) would pass this flag. 3. UpdateTotalIssuesOnCirc becomes cheap enough to enable by default: A DB column update plus a reindex queue entry per checkout is trivial. The Elasticsearch indexer already batches indexing tasks efficiently. 4. update_totalissues.pl is simplified: It recalculates biblioitems.totalissues from statistics/items data and triggers batch reindexing. It no longer touches MARC records at all. It should also gain a --commit option to control batch sizes for the reindex step. ## Expected impact - Real-time totalissues updates on checkout with negligible performance cost - update_totalissues.pl runtime reduced from hours to minutes (DB updates + batch reindex vs per-record ModBiblio) - No more MARC record churn for a derived counter value - Reduced action_logs noise (no cataloguing log entries for counter updates) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 41980] New: SIP codes in the new SIP Config UI could have better descriptions
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41980 Bug ID: 41980 Summary: SIP codes in the new SIP Config UI could have better descriptions Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 37893 Now we have a nice systems librarian facing SIP configuration page, it would be nice to improve the field descriptions from many simple SIP codes to something a little more understandable for the person doing the configuration should they not be a SIP expert. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 [Bug 37893] Migrate some SIP configuration into the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[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