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

[Bug 41249] New: ILL batches should be compatible with AutoILLBackendPriority
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41249 Bug ID: 41249 Summary: ILL batches should be compatible with AutoILLBackendPriority Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com AutoILLBackendPriority suggests the top most available backend in priority when creating a new ILL request. This should also work the same when creating requests through the ILL batches functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 41111] New: AutoILLBackendPriority should consider a 'yellow' stage
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41111 Bug ID: 41111 Summary: AutoILLBackendPriority should consider a 'yellow' stage Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Previously only 'red' and 'green' existed, for can't place/unavailable and can place/its available. 'Yellow' now means the backend can place - but can't confirm that it'll be supplied or it requires additional confirmation to place it. Functionality this should work in the following manner: 1) 'Yellow' backends are only suggested by Koha in the Staff UI if no other 'green' backends exist 2) Koha still suggests the first 'green' backend even if a 'yellow' one is higher in priority 3) OPAC ignores this completely. Only 'green' backends are still picked as the goto backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 30557] New: Add ability to create Item lists
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30557 Bug ID: 30557 Summary: Add ability to create Item lists Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is relevant for multi-branch installations. Lists currently appear to be primarily bibliographic lists. This creates a problem when sorting lists by call number. In this scenario there may be multiple items from different libraries using different call number schema attached to a single bibliographic record. The list cannot be sorted accurately by call number. It would be helpful if there was an option for an item based list. In this scenario items are added to a list for a specific branch. The call number sort will then sort correctly because the call number schema will be consistent for the branch. An item list would display the same information as a bibliographic list with the exception of additional branches which may also have the item. A typical use case would a library creating an item list, sort by call number, and then use that list to go to the shelf to pull the items in order. This is currently not possible in a multi-branch installation without a bit of work. It would require downloading the list and then cleaning up the list to be useful for this kind of work. It may be possible to create a report that will do this, but it would be a nice added functionality in the List tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 240

[Bug 42890] New: EDI INVOIC processing should create/link items in aqorders_items when AcqCreateItem=receiving
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42890 Bug ID: 42890 Summary: EDI INVOIC processing should create/link items in aqorders_items when AcqCreateItem=receiving Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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 Target Milestone: --- When AcqCreateItem is set to 'receiving', items are expected to be created during the acquisitions receiving step. In a non-EDI workflow this happens via the staff UI (acqui/receive.pl -> ModReceiveOrder). In an EDI workflow, processing the INVOIC message is the functional equivalent of that receiving step -- the goods are confirmed shipped, prices and quantities are reconciled, and the order lines are closed. However, Koha::EDI::receipt_items (EDI.pm ~L500) currently only updates items that already exist in aqorders_items (i.e. created at ordering time). When AcqCreateItem=receiving, no aqorders_items rows exist at the point the INVOIC is processed, so: 1. The GIR segment data (branch, barcode, etc.) is silently discarded -- items are never created. 2. aqorders_items remains empty, so physical receipt tracking (Bug 40932 -- "automatic invoice closing on physical item receipt") cannot function for EDI+receiving workflows. What should happen: When AcqCreateItem=receiving and an EDI INVOIC is processed, receipt_items should: 1. Create catalogue items from the GIR segment data (mirroring what ModReceiveOrder does for the UI path). 2. Populate aqorders_items rows linking the new items to their order lines, with the 'received' column left NULL. The 'received' timestamp should remain unset at this stage: the INVOIC represents the vendor confirming shipment, not confirmed physical arrival. Physical arrival is recorded at circulation check-in, which stamps 'received' and (via Bug 40932) triggers invoice auto-close. Steps to reproduce: 1. Set AcqCreateItem = receiving. 2. Create an order via a vendor with EDI enabled. 3. Import an INVOIC message for that order. 4. Observe: no items are created; aqorders_items remains empty; subsequent check-in cannot stamp receipt or auto-close the invoice. See also: Bug 40932 (automatic invoice closing on physical item receipt -- scoped to AcqCreateItem=ordering precisely because of this gap). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 40932] New: Automated trigger for invoice closure
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40932 Bug ID: 40932 Summary: Automated trigger for invoice closure 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 would like to see the ability to set a trigger for a series of actions that would close an invoice automatically without us manually going into the invoice and ticking close and saving. We want to see a workflow whereby once all items associated to an invoice, when they are all returned for the first time this would trigger a cron job to close the invoice. This would help us to automate our acquisitions checking processes. Currently a staff member has to run a report and check in with staff to make sure they have returned items and then they spend a considerable time checking through for each invoice to make sure items have been physically received and then closing the invoice. If we can automate this last step so that when all items are checked in for the first time, the invoice will automatically close. It would also be useful to have this automatic action as a cron job so that if something goes wrong we could interrupt the next run and correct. Also, the ability to reopen the invoice is also the other failsafe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 41169] New: Cancelling order from a basket doesn't warn about removing items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41169 Bug ID: 41169 Summary: Cancelling order from a basket doesn't warn about removing items Initiative type: --- Sponsorship --- status: 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: mikko.liimatainen(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org When cancelling an order in a basket there is no warning about item deletion. This can be a problem if the item is already in circulation. If the items attached to the order can not be removed, this is given a notification as the order has been cancelled. When you are cancelling an order you get a confirmation page with this text: "Are you sure you want to cancel this order (45) Bibliographic record will not be deleted." I'd like there to be a mention that the items of this order will be deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43803] New: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting)
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Bug ID: 43803 Summary: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Steps to reproduce: 1. Create an item-level hold on an item currently checked out to patron A (hold by patron B). 2. Workstation 1: check in the item. The "Hold found" modal appears with the "Confirm hold" button. Leave this modal open. 3. Workstation 2 (or another tab): check out the same item to patron C. The "This item is reserved" confirmation appears. Confirm the checkout without cancelling the hold (force checkout is allowed). 4. Back on workstation 1: click "Confirm hold" in the still-open modal. Expected result: The hold confirmation is refused (or the hold is left pending), because the item is now on loan. The hold should not be set to waiting while the item is checked out. Actual result: The hold is set to waiting (found = 'W') even though the item is on loan to patron C. The item ends up both on loan and on the hold shelf ("waiting for pickup"). No warning is shown to the librarian at step 4. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43870] New: EDIFACT message with no BGM segment stops edi_cron.pl
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43870 Bug ID: 43870 Summary: EDIFACT message with no BGM segment stops edi_cron.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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: 43757 Target Milestone: --- Follow-up to bug 43757. That bug makes Koha::Edifact->new throw Koha::Exceptions::FileNotParsed for an empty transmission, a missing or unsupported UNA and an interchange containing no messages, and makes process_invoice, process_quote and process_ordrsp record the failure against the message (status 'error' plus an edifact_errors row) and carry on. A malformed message inside an otherwise valid interchange is not covered. Koha::Edifact::Message->new assumes the second segment is a BGM and that at least one segment follows the BGM and any DTM segments: my $bgm = shift @{$data_array_ref}; my $msg_function = $bgm->elem(2); ... while ( $data_array_ref->[0]->tag eq 'DTM' ) { A message with no BGM dies with: Can't call method "elem" on an undefined value. A message that ends after its BGM and DTM segments dies in the while loop in the same way. Koha::Edifact->message_array, which builds the Message objects, is called by process_invoice, process_quote and process_ordrsp outside any error handling. The exception therefore stops edi_cron.pl: the remaining messages and accounts are not processed and the message is left in status 'processing'. Proposed changes: a. Koha::Edifact::Message->new throws Koha::Exceptions::FileNotParsed ("Message has no BGM segment") when the second segment is not a BGM, and the DTM loop stops at the end of the segments. b. The exception is raised on the first call to message_array, not when the Koha::Edifact object is constructed. c. process_invoice, process_quote and process_ordrsp catch it around message_array and handle it as bug 43757 does for a failed parse: status 'error', an edifact_errors row with the reason, a log entry, and carry on with the next message. Test plan: 1. Add an INVOICE to edifact_messages (status 'new') whose raw_msg is: UNA:+.? 'UNB+UNOC:3+TEST+KOHA+200101:0000+1'UNH+1+INVOIC'UNT+1+1'UNZ+1+1' followed by a second, valid INVOICE. 2. Run misc/cronjobs/edi_cron.pl (or process_invoice on both messages). 3. Without the patch: the cron dies on the first message, which is left in status 'processing'. 4. With the patch: the first message has status 'error' with a row in edifact_errors ("Message has no BGM segment") and the second is processed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43757 [Bug 43757] EDIFACT parser drops syntax 4 interchanges silently and dies on a missing UNA -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41451] New: Hold history search fails when itemtype column present
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41451 Bug ID: 41451 Summary: Hold history search fails when itemtype column present Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The search box on the holds history table throws a 500 error when the item type column is visible Test plan: 1) Create at least one hold on any record 2) Navigate to the patron who has the hold and click Holds history in the left menu 3) The table should load correctly and the search bar above it should work 4) In system preferences, enable AllowHoldItemTypeSelection 5) Refresh the holds history, the Requested item type column should now be visible 6) Try a search, a 500 error should be thrown -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 43873] New: Patron messages via email or SMS silently fail when selected template has no content
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43873 Bug ID: 43873 Summary: Patron messages via email or SMS silently fail when selected template has no content Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW 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 Depends on: 40933 Target Milestone: --- When using the "Add message" button in the patron record to send a patron message via email or SMS, the interface lists all existing letters in the "Patrons (custom message)" module, regardless of whether or not that letter has email or sms content defined. Ideally, the "Patron notice" dropdown would list only letters with email content when "Add a message for" is set to email and only letters with sms content when "Add a message for" is set to SMS. Failing that, Koha should at least return an alert when no notice is enqueued due to lack of content. To recreate: - have a patron with both an email address and an SMSalertnumber - create a notice template in the module "Patrons (custom message)" - in your template, only put content in the Print section - on your patron, click "Add message" - set "Add a message for" to email, select your notice template, click Save - see no email has been enqueued for your patron - on your patron, click "Add message" - set "Add a message for" to SMS, select your notice template, click Save - see no SMS has been enqueued for your patron Referenced Bugs: 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 the assignee for the bug. You are watching all bug changes.

1 0