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

[Bug 43292] New: Patron screen_msg can contain unescaped CR/LF, corrupting SIP2 message framing
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43292 Bug ID: 43292 Summary: Patron screen_msg can contain unescaped CR/LF, corrupting SIP2 message framing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 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: --- Koha::Patron::Message already has a message_without_newlines method specifically to protect SIP2 patron-message screen_msg composition from embedded newlines, but two other sources that feed into a patron's screen_msg - the OPAC note (opacnote) and a restriction's debarredcomment, both composed in C4::SIP::ILS::Patron - are not sanitized before being sent as a SIP2 FID_SCREEN_MSG field. Since SIP2 messages are CR-terminated on the wire, a literal CR or LF inside a patron's OPAC note or restriction comment (both plain text fields editable via the staff interface / OPAC) can prematurely terminate the message and desync the self-check client's parser. This patch sanitizes the patron screen_msg immediately after reading it in build_patron_status and handle_patron_info, matching the exact CR/LF-stripping approach already used by Koha::Patron::Message->message_without_newlines. Test plan: 1. Add an OPAC note (or a restriction comment) containing an embedded newline to a patron, e.g. via the staff client's patron notes field 2. Send a SIP2 Patron Status Request (or Patron Information request) for that patron 3. Before this patch: the FID_SCREEN_MSG field in the raw response contains an embedded CR/LF, corrupting the message framing 4. Apply the patch and repeat step 2 5. The screen message is present but any CR/LF has been collapsed to a space, and the response is well-formed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25267] New: OPAC Browse Shelf feature is not responsive
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25267 Bug ID: 25267 Summary: OPAC Browse Shelf feature is not responsive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC the browse shelf feature is not responsive. To recreate: 1. Turn on OPACShelfBrowser. 2. If youre using test data you will have to give some items call numbers. I did: update items set itemcallnumber = 'acallnumber'; 3. It will also be best if you add some cover images. 4. Go to an item detail page and Browse Shelf. 5. The feature looks good until the viewport is about 1700px or less. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 42440] New: Remove event attributes from labeled MARC detail template
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42440 Bug ID: 42440 Summary: Remove event attributes from labeled MARC detail template Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 38407 catalogue/labeledMARCdetail.tt has an "onChange" event attribute which is redundant. There's already a version of that event handler in the JS block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43290] New: Cashup summary totals can carry excess decimal precision
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43290 Bug ID: 43290 Summary: Cashup summary totals can carry excess decimal precision Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: martin.renvoize(a)openfifth.co.uk Target Milestone: --- Koha::Cash::Register::Cashup->summary sums accountlines.amount (a decimal(28,6) column) via MySQL SUM() and then Perl addition to build the top-level 'total' field and each entry in 'total_grouped'. These sums can come back with more precision than the 2 decimal places these amounts are ever displayed or entered at, and the extra digits pass straight through the /api/v1/cashups/:id JSON response since neither field is otherwise formatted. This patch sprintf's both derived sums to 2 decimal places, matching the amounts they represent. The per-row income_grouped/payout_grouped entries are untouched, since they are a straight get_column() * -1 negation rather than a Perl-side addition of two separately-summed values. Test plan: 1. prove t/db_dependent/Koha/Cash/Register/Cashup.t 2. prove t/db_dependent/Koha/Cash/Register/Cashups.t 3. prove t/db_dependent/api/v1/cashups.t 4. Complete a cashup with several payment types and confirm the summary modal's Total and per-payment-type rows show a clean 2 decimal place amount -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43289] New: TypeError in cashup summary modal when API returns totals as strings
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43289 Bug ID: 43289 Summary: TypeError in cashup summary modal when API returns totals as strings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: martin.renvoize(a)openfifth.co.uk Target Milestone: --- format_price() is only defined on Number.prototype (see koha-tmpl/intranet-tmpl/prog/en/includes/format_price.inc), but the /api/v1/cashups/:id summary endpoint's grouped and total amounts (out.total, income.total, type.total, data.summary.total, and the derived cashCollected/actualAmount) can come back as strings - DECIMAL columns are frequently stringified by the DB layer before JSON encoding. Calling e.g. out.total.format_price() on a string throws "TypeError: out.total.format_price is not a function", which aborts the rest of the AJAX success handler and leaves the cashup summary modal partially or fully unrendered. This patch wraps every such value in Number(...) before calling format_price(). It also fixes the "Other payment types collected" filter, which compared type.total !== 0 with strict inequality - always true when type.total is a string, so a $0.00 payment type could show a spurious row in the summary. Test plan: 1. Configure more than one payment type in the CashupPaymentTypes system preference 2. Complete a cashup (pos/register.pl) with income/payout/refund transactions across several payment types, including at least one with a zero total for some payment type 3. Click the cashup's "Summary" link to open the cashup summary modal 4. Before this patch: open the browser console - a TypeError is thrown and the modal's table/footer is only partially populated (or a spurious $0.00 payment type row appears) 5. Apply the patch and repeat step 3 6. The modal renders fully and correctly, with no console error and no spurious zero-amount row -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42732] New: Migrate catalogue/detail.tt addToBundle $.post to api-client.js
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42732 Bug ID: 42732 Summary: Migrate catalogue/detail.tt addToBundle $.post to api-client.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com catalogue/detail.tt (line 1969) uses $.post() to call /api/v1/items/{id}/bundled_items. This should be migrated to use api-client.js which already handles CSRF token injection. This is a prerequisite for enforcing CSRF protection on the REST API (Bug 34451). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42731] New: Migrate modal-claims.inc $.post to api-client.js
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42731 Bug ID: 42731 Summary: Migrate modal-claims.inc $.post to api-client.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com modal-claims.inc (line 87) uses $.post('/api/v1/return_claims', ...) directly. This should be migrated to use api-client.js which already handles CSRF token injection. This is a prerequisite for enforcing CSRF protection on the REST API (Bug 34451). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42730] New: Migrate place_booking.js $.post to api-client.js
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42730 Bug ID: 42730 Summary: Migrate place_booking.js $.post to api-client.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com place_booking.js (line 2357) uses $.post() directly to call the REST API. This should be migrated to use api-client.js which already handles CSRF token injection. This is a prerequisite for enforcing CSRF protection on the REST API (Bug 34451). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 43291] New: SIP2 responses hardcode currency to USD regardless of library configuration
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43291 Bug ID: 43291 Summary: SIP2 responses hardcode currency to USD regardless of library configuration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 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: --- C4::SIP::ILS::Transaction's sip_currency field (used for FID_CURRENCY in patron status and fee-related SIP2 responses) is hardcoded to 'USD' with a "FIXME: why hardcoded?" comment, regardless of the library's actual currency. Any library using a self-check/SIP2 integration outside the US gets an incorrect currency code in every fee-related SIP2 response. This patch uses Koha::Acquisition::Currencies->get_active's isocode when one is configured, falling back to 'USD' (the previous, and still sensible default, behaviour) when no active currency exists. Every C4::SIP::ILS::Transaction subclass calls SUPER::new() first and none of them override sip_currency in their own %fields, so this applies uniformly across checkout, checkin, renew, hold, and fee payment SIP responses. Test plan: 1. prove t/db_dependent/SIP/Transaction.t 2. With no active currency configured, confirm a SIP2 patron status response still reports USD (AY field / currency) 3. Mark a currency (e.g. GBP) as active in Administration > Currencies 4. Repeat step 2 and confirm the response now reports GBP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 38358] New: To date don't follow when you are editing holidays
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38358 Bug ID: 38358 Summary: To date don't follow when you are editing holidays Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 173981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173981&action=e… To date does not follow the From date and you must find the right date manually When you are editing holidays "To date"-calendar don't follow the "From date"-date. Instead "To date"-calendar offers you today's date/month and you must click calendar forward to the right date/month. It would be nice if it worked like this: "To date"-calendar follows the date you put in "From date"-box. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18