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

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

[Bug 40075] New: ILL Standard form should only show libraries that are pickup_locations
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40075 Bug ID: 40075 Summary: ILL Standard form should only show libraries that are pickup_locations Change sponsored?: --- 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: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Additionally, libraries should be listed alphabetically on branchname, since that is what is displayed to the user. Existing pattern to adopt: https://github.com/Koha-Community/Koha/blob/24.11.x/Koha/Item.pm#L1066 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 39918] New: Unauthenticated request data should show when editing a request
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39918 Bug ID: 39918 Summary: Unauthenticated request data should show when editing a request Change sponsored?: --- 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: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 36917 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36917 [Bug 36917] Many warnings from t/db_dependent/Authority/Merge.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 39786] New: ILL get_notice errors if request does not have a patron
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39786 Bug ID: 39786 Summary: ILL get_notice errors if request does not have a patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: martin.renvoize(a)openfifth.co.uk, nick(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 36197 Koha allows for ILL requests without patrons, and since bug 32630 this may happen more often. Backends compatible with ILLOpacUnauthenticatedRequest will likely have requests without patrons associated, but may still need to make use of Koha::ILL::Request::get_notice (e.g. Koha2Koha backend https://gitlab.com/koha-community/plugins/koha-plugin-ill-koha) get_notice should be more defensive and consider the possibility of the request not having a patron. Core Koha should handle this validation, the alternative is every backend in this scenario needs to handle it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36197 [Bug 36197] Allow unauthenticated ILL requests in the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 39774] New: OPAC ILL Unauthenticated request details table not styled correctly
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39774 Bug ID: 39774 Summary: OPAC ILL Unauthenticated request details table not styled correctly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 39697] New: ILL OPAC unauthenticated form is not centered
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '26

08 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39697 Bug ID: 39697 Summary: ILL OPAC unauthenticated form is not centered Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 36197 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36197 [Bug 36197] Allow for OPAC unauthenticated ILL request -- You are receiving this mail because: You are watching all bug changes.

1 11