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

[Bug 33364] New: Stop Holds to Pull report showing items that have been allocated to a recall
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33364 Bug ID: 33364 Summary: Stop Holds to Pull report showing items that have been allocated to a recall Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Holds to Pull report shows an item with a hold if the item is available on the shelf, ready to pull and allocate to the hold. The Holds to Pull should NOT show an item with a hold if that item has already been allocated to a recall (i.e. the recalled item is awaiting pickup and or in transit for a patron). To reproduce: 1. Enable UseRecalls and set the recalls-related circulation rules 2. Check out an item to Patron A 3. Place a hold on the item for Patron B 4. Log into the OPAC as Patron C and search for the item. Place a recall on the item. 5. Go back to the staff interface. Go to Circulation -> Holds to pull 6. Confirm the item shows in the Holds to pull table, with the hold for Patron B 7. Check in the item and confirm the recall as waiting 8. Go back to the Holds to pull page. You could manually regenerate the page but running the cronjob in the terminal misc/cronjobs/holds/build_holds_queue.pl 9. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 42714] New: Koha::Script should automatically log start and end of scripts when they are run
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42714 Bug ID: 42714 Summary: Koha::Script should automatically log start and end of scripts when they are run Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Currently, our scripts/cronjobs are expected to add cronlogaction calls at the start and end to ensure they are recorded in the action logs. This is tricky as we have to maintain these lines in all cron scripts An easier way to do this is to add INIT and END blocks to Koha::Script - these can log the run, and require only one line per file to add the logging. Adding to Koha::Script will mean that any command line script using it will be recorded, but I think this is actually a benefit and makes tracing actions easier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 43295] New: Add ability to report external authentication service failures when falling back to local auth
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43295 Bug ID: 43295 Summary: Add ability to report external authentication service failures when falling back to local auth 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an authentication service is down ( say LDAP ), Koha will fall back to local authentication. The only indicator of this happening are slow login times. It would be good to store these failures as errors somewhere in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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