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

[Bug 26036] New: Suggestion for the "Batch extend due dates" result screen
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26036 Bug ID: 26036 Summary: Suggestion for the "Batch extend due dates" result screen Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: tgoatley(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As suggested and on behalf of the Arlington Public Library in Arlington, VA - It would be very helpful to have a count of the number of items about to be adjusted and/or a way to export the results in order to understand how these adjustments would impact the system and public services staff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 41310] New: Add remote_ip (REMOTE_ADDR) to action_logs table to improve security auditing
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41310 Bug ID: 41310 Summary: Add remote_ip (REMOTE_ADDR) to action_logs table to improve security auditing 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: saiful(a)semanticconsulting.com QA Contact: testopia(a)bugs.koha-community.org Context: Currently, the action_logs table records what happened, when it happened, and who performed the action. However, it does not record the network context (source IP) of the request. The Problem: For security auditing, it is necessary to trace an action back to a specific IP address. This is critical when: 1. A staff account is compromised (distinguishing the attacker from the real user). 2. Multiple concurrent sessions exist for the same user (e.g., logged in at the desk and on a mobile device). The Session data: The sessions table in Koha is temporary, which may even be stored cache or filesystem. If we store the session_id in action_logs, we can only link it to an IP address while the session is still active. Once the session is cleared, we will lose the IP address history. Proposed Solution: We should capture the REMOTE_ADDR at the time the action occurs and store it directly into a new column in the action_logs table. This ensures the audit trail remains complete permanently, regardless of the session status. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 42788] New: EDI ORDRSP: Fund encumbrance not released when order line cancelled by supplier
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42788 Bug ID: 42788 Summary: EDI ORDRSP: Fund encumbrance not released when order line cancelled by supplier 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 When an EDI ORDRSP message cancels an order line, Koha updates the order status to 'cancelled' but does not release the fund encumbrance. The budget remains committed to the cancelled order indefinitely, preventing those funds from being used for replacement orders. The processing logic is in Koha/EDI.pm, process_ordrsp() (~line 199-248). Manual cancellation via the acquisitions UI does release the encumbrance, but the EDI code path does not. This patch should release the fund encumbrance when an order line is cancelled via EDI ORDRSP, ideally guarded by a system preference so libraries can choose the behaviour that suits their workflow. Test plan: 1. Place an order against a fund with a known balance; note the encumbered amount. 2. Receive an EDI ORDRSP cancellation for that order line and run edi_cron.pl. 3. Confirm the order line is marked cancelled. 4. Confirm the fund encumbrance has been released and the available balance restored. 5. Test with the system preference disabled to confirm encumbrance is retained. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42787] New: EDI ORDRSP: No staff notification triggered when an order line is cancelled by supplier
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42787 Bug ID: 42787 Summary: EDI ORDRSP: No staff notification triggered when an order line is cancelled by supplier 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 When an EDI ORDRSP message is received containing a cancellation (action code 2), Koha marks the order line as cancelled (via C4::Acquisition::ModOrder) but generates no staff-visible notification, email, or alert. Staff have no way to know a cancellation was processed unless they manually inspect the order or check the acquisitions log. In busy libraries this means cancellations can go unnoticed for days. The processing logic is in Koha/EDI.pm, process_ordrsp() (~line 199-248). This patch should add a staff notification (e.g. via the existing notice/ messaging infrastructure) when an order line is cancelled via EDI ORDRSP, so that the relevant librarian is alerted promptly. Test plan: 1. Configure EDI for a vendor and send an ORDRSP containing a cancellation (action code 2) for an existing order line. 2. Run the EDI cron: misc/cronjobs/edi_cron.pl 3. Confirm the order line is marked cancelled in acquisitions. 4. Confirm that an appropriate staff notification has been triggered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

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

08 Jun '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 26

[Bug 39948] New: Unauthenticated ILL form cluttered in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39948 Bug ID: 39948 Summary: Unauthenticated ILL form cluttered in the OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are labels like: * Unauthenticated first name * Unauthenticated last name * Unauthenticated email 'Unauthenticated' feels like an internal thing for staff, and something really weird for an end user to read. It already displays in the 'Status' row. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42499] New: External payments into Point of Sale
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42499 Bug ID: 42499 Summary: External payments into Point of Sale Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk We would love to see the ability for POS to receive logs (via APIs) of payments taken via external systems. This would allow us to use POS as our central banking system for cashing up. For example, we use Bibliotheca kiosk with an integration for Netloan for which we receive payments for bookings and printing. There is a SIP2 connection to Koha for end user authentication but the log of the transaction stays on the Bibliotheca kiosk and doesn't go anyway. Our library staff have to run the z report each night from the kiosks to find out how much was taken in Netloan income and then manually key into to Koha in POS as a transaction and pay. So, we want Koha to add the bill and then set as paid and journaled against the correct cash register so this income is automatically included in cashing up via POS. This would benefit us as less manual and reduces human error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42785] New: REST API: Add atomic external payment intake endpoint for patron-linked charges from third-party systems
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42785 Bug ID: 42785 Summary: REST API: Add atomic external payment intake endpoint for patron-linked charges from third-party systems Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When an external system (self-service kiosk, third-party POS terminal, payment gateway) needs to record a completed patron payment in Koha, it currently requires two sequential API calls: 1. POST /patrons/{patron_id}/account/debits â create the charge 2. POST /patrons/{patron_id}/account/credits â record the payment against it This two-step flow has practical problems for external integrations: - It is not atomic: a failure between the two calls leaves an unpaid debit on the patron's account - External systems typically have a single "payment completed" event to record, not separate "charge" and "pay" steps - The correct debit to credit linkage (via account_offsets) must be managed by the caller A new endpoint oriented at external payment intake would allow this in a single call: POST /patrons/{patron_id}/account/payments ...accepting a debit_type, amount, description, payment_type, and optionally a register_id (to journal against a POS cash register), and atomically creating the debit, the credit, and the offset linking them. This mirrors what happens internally in the SIP2 FeePayment path (which creates a charge-and-pay in one transaction) and makes the REST API a first-class integration surface for external payment systems such as Bibliotheca kiosks with Netloan, self-checkout terminals, and payment gateways. Use case: A Bibliotheca kiosk authenticates a patron via SIP2 and takes payment for a booking or printing job. The kiosk should be able to POST a single "payment received" record to Koha â creating the income line and immediately marking it as paid, journaled to the correct cash register â without managing a two-step debit/credit dance. Test plan: 1. Identify a patron with no outstanding charges 2. POST to /api/v1/patrons/{patron_id}/account/payments with debit_type, amount, payment_type, and a valid register_id 3. Confirm a debit and a credit line are both created in accountlines, linked via account_offsets, with amountoutstanding = 0 on the debit 4. Confirm the patron's account balance is unchanged (net zero) 5. Confirm the transaction appears in the specified cash register's daily total -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42784] New: REST API: Add endpoint for patron-optional POS sales to support external payment system integration
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42784 Bug ID: 42784 Summary: REST API: Add endpoint for patron-optional POS sales to support external payment system integration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Koha's Point of Sale module already supports counter-sales without a patron (via Koha::Charges::Sales, which creates accountlines rows with NULL borrowernumber, journaled to a cash register). However, this functionality is only accessible through the staff web interface â there is no REST API equivalent. External self-service systems (kiosks, vending machines, third-party payment terminals like Bibliotheca/Netloan) need a way to POST payment records directly into Koha's POS cash register without those payments being tied to a specific patron. Currently the only REST API endpoints for payments require a patron_id in the path (/patrons/{patron_id}/account/credits), making anonymous/non-patron transactions impossible via the API. A new endpoint such as: POST /cash_registers/{cash_register_id}/sales ...that accepts a debit_type, amount, description, and payment_type (and creates both the debit and credit lines atomically, journaled to the specified register) would allow: - External kiosks to push their daily takings into Koha's POS automatically - Library staff to use Koha POS as a central banking/cash-up system for all income streams - Elimination of manual keying of external system income at end of day This is the missing REST API surface over the existing Koha::Charges::Sales code path. Use case example: A Bibliotheca kiosk with Netloan integration collects payments for bookings and printing. There is a SIP2 connection to Koha for patron authentication, but income not tied to a specific patron (or where the patron context is irrelevant to the income recording) cannot currently be pushed into Koha's cash register via API. Staff must run a z-report from the kiosk and manually enter totals into POS each night. Test plan: 1. Ensure you have at least one cash register configured in Koha 2. Send a POST request to /api/v1/cash_registers/{id}/sales with a valid debit_type, amount, description, and payment_type 3. Confirm a debit and credit line are created in accountlines with NULL borrowernumber and the correct register_id 4. Open the POS cashing-up view and confirm the transaction appears in the register's daily total -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25314] New: Make OPAC facets collapse
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25314 Bug ID: 25314 Summary: Make OPAC facets collapse Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I propose making facets collapse by defualt. I don't think we need to continue to have 'Show less' and 'Show more' buttons. If everything is collapsed by default we can show everything within that list when it is expanded. -- You are receiving this mail because: You are watching all bug changes.

1 60