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

[Bug 42792] New: Add option in inventory tool for staff to be warned if an item is out of order
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42792 Bug ID: 42792 Summary: Add option in inventory tool for staff to be warned if an item is out of order Initiative type: --- Sponsorship --- status: 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: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, if staff opt to check for out of order inventory items and an out of order item is scanned, the staff person continues to be warns about the item until they reach the place where the item should go. Some libraries would prefer to be warned that an item is out of order but then they'd like the warning to go away, or they'd like to dismiss the warning. They don't want to continue to be warned after finding the odd item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42136] User-entered Template::Toolkit allows information disclosure
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

1 0

[Bug 42224] (Bug 40524 follow-up) [24.11.x] Fix XSS in columns_settings.inc
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

1 0

[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 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 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