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

[Bug 20582] New: Turn Koha into a Mojolicious application (?)
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582 Bug ID: 20582 Summary: Turn Koha into a Mojolicious application (?) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 158

[Bug 42113] New: Add ability to enable/disable bundles
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42113 Bug ID: 42113 Summary: Add ability to enable/disable bundles Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For libraries that do not use bundles, it would be helpful to have the option to disable or enable the ability of Koha to read the leader to create a bundle even if the collection indicator exists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41781] New: Holds queue builder ( build_holds_queue.pl ) fails if HoldsQueueParallelLoopsCount is greater than 1
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41781 Bug ID: 41781 Summary: Holds queue builder ( build_holds_queue.pl ) fails if HoldsQueueParallelLoopsCount is greater than 1 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(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 HoldsQueueParallelLoopsCount is set to a value greater than 1, build_holds_queue.pl will fail with the message: Can't locate object method "new" via package "Parallel::ForkManager" (perhaps you forgot to load "Parallel::ForkManager"?) at /kohadevbox/koha/C4/HoldsQueue.pm line 205. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 37402] New: Task scheduling fails if you don't use the correct time format
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37402 Bug ID: 37402 Summary: Task scheduling fails if you don't use the correct time format Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Task Scheduler Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org It looks like one must enter a time in the format 00:00 or you will be unable to save the task. The page reloads with the message "Failed to add scheduled task" and no other information about why it failed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 40154] New: Deleting an item does not warn about an item level hold
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40154 Bug ID: 40154 Summary: Deleting an item does not warn about an item level hold 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: anni.maki-mantila(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl At the moment, Koha doesn't give any warning if user is deleting an item that has a hold attached to it. Item is simply deleted and the item level hold vanishes as well. To reproduce: 1. Make an item level hold 2. Delete the item using alternative A or B: A: Open the biblios Detail-view -> From the toolbar, open "Edit"-dropdown menu -> Manage items -> Delete the item that has an item level hold attached to it from "Actions"-dropdown menu B: Open the biblios Detail-view -> Select the item that has an item level hold attached to it -> Click "Delete selected items" -> Confirm deletion 3. Notice that the item is deleted without any warning and the item level hold has disappeared 4. Run following sql report: SELECT * FROM old_reserves WHERE biblionumber = [biblionumber you used in the test] 5. Notice that the item level hold is not found in old_reserves-table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 40134] New: Fix and optimise 'Any item' functionality of bookings
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40134 Bug ID: 40134 Summary: Fix and optimise 'Any item' functionality of bookings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 29002 The 'Any item' option in the bookings modal is currently not correctly calculating maximum available booking window correctly and we have older code left behind that attempted to allow any item at a biblio level without taking into account item type limitations. This bug acts to correct that by implementing an optimized algorithm for picking the item at booking time to try and maximize the pool of available items for future bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 39781] New: Cannot limit by library when creating custom patron email sent via patron details page
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39781 Bug ID: 39781 Summary: Cannot limit by library when creating custom patron email sent via patron details page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29393 To recreate: 1 - create a new notice in module "Patrons (custom message)" 2 - limit your notice to a library 3 - give your notice content for the email format 4 - go to a patron record, select Add Message 5 - confirm the notice you created appears as an option regardless of whether or not you're logged in at the branch you selected in step 2 6 - confirm the Save button fails to enqueue your notice, regardless of logged-in branch We don't pass any branchcode along with the borrowernumber and letter_code when enqueueing this, so it fails if the notice template is limited to a branch. We should send the logged-in library when enqueueing the notice. We should also high the notice from the Add Message form if the user is not logged in at the correct branch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 42083] New: Email and SMS messages from patron record should have distinct permissions
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42083 Bug ID: 42083 Summary: Email and SMS messages from patron record should have distinct permissions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 40933, 29393 Bug 29393 added the ability to send email from a patron's record. 40933 expanded that to SMS. But they currently share a single permission. It would be preferable for those to be two distinct permissions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40933 [Bug 40933] Add SMS support under Add message feature -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 42203] New: Add information to authorities' summary
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42203 Bug ID: 42203 Summary: Add information to authorities' summary Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In some cataloguing environments, it is important to have access to additional information when selecting an authority record while cataloging (e.g. the series ISSN, the identifier of the original record, the thesaurus from which the heading originates--especially in the case of identical or similar headings). At present, verifying this requires opening each record individually, which is cumbersome. Adding configurable identifier information to the summary in the authority search results would be very helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41765] New: Autobarcode incremental barcodes are generated with +7 value instead of +1 value
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41765 Bug ID: 41765 Summary: Autobarcode incremental barcodes are generated with +7 value instead of +1 value Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: talsisunstorm(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 192439 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192439&action=e… Sequenve of generated barcodes of added items After updating to v25.11 (from v24.11), the autoBarcode feature generates number with incremental value of +7 and not +1 as expected (see attachment). In v24.11 this worked fine. How to reproduce: 1. set autoBarcode to incremental EAN-13 barcodes in Cataloging preferences -> Record structure 2. set barcode.pl as plugin in Tag 952p in MARC bibliographic framework 3. create new or open existing record 4. add new item 5. click into p - Barcode field to generate barcode 6. repeat step 4 & 5 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1