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

[Bug 43267] New: Batch operations from datatables report view should only send visible results (same as standard view)
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43267 Bug ID: 43267 Summary: Batch operations from datatables report view should only send visible results (same as standard view) Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42190 Target Milestone: --- Created attachment 203428 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203428&action=e… Screenshot showing 'Batch operations with....' button from reports datatables view Sending results to batch operations from the new datatables report view should only send visible results (that is, it should work the same way as sending results from the standard report view). Staff can send *visible* results to batch operations from a report that contains columns for borrowernumber, biblionumber, itemnumber, or cardnumber. However, when using the new datatables feature, all report results are sent to batch operations, not just the visible results. To add extra confusion, the button for batch operations from the datatables view reads 'Batch operations with [total results number] visible records', even when the default 20 records are visible (see attached screenshot). If I change nothing and send results to batch operations as is, all results (not just the 20 visible) are sent. Only visible results should send to batch operations from the datatable view so that it works the same way as sending results to batch operations from the standard report view. (Or, all report results from the standard view should be sent for batch operations, not only the visible results.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42190 [Bug 42190] Add datatables to reports -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 43211] New: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order'
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43211 Bug ID: 43211 Summary: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order' Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com Blocks: 41563 Target Milestone: --- Koha hangs when receiving an order with AcqCreateItem set to "receiving an order". The JavaScript console shows: Uncaught TypeError: unique_item_fields.split is not a function This is most likely caused by the changes introduced in bug 41563. Koha.addPrefs({ [...] UniqueItemFields: [% Koha.Preference('UniqueItemFields') ? 1 : 0 | html %], }); UniqueItemFields should not be reduced to a number. It is expected to be a string containing a list of item fields separated by pipes (|), which is why the code later calls split() on it. To reproduce: 1. Create a basket and set "Create items when" to "receiving an order". 2. Add an order and close the basket. 3. Attempt to receive the order. Koha will most likely hang. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41563 [Bug 41563] Tidy kohaTable block - acqui -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 42605] New: Acquisition Items not listed during receipt
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 Bug ID: 42605 Summary: Acquisition Items not listed during receipt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Ensure AcqCreateItem is set to 'placing an order' at syspref or on basket 2 - Open a basket, add an order, and add several items 3 - Close the basket and receive shipments 4 - Select the order and 'Receive selected' or click 'Receive' on the order 5 - No items are listed in the items section -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 43851] New: SFTP_FAILURE and SFTP_SUCCESS are in non existing module
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43851 Bug ID: 43851 Summary: SFTP_FAILURE and SFTP_SUCCESS are in non existing module Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- Notices SFTP_FAILURE and SFTP_SUCCESS are in the module commandline but this module doesn't seem to exist: - you can't create a new notice in this category - when you edit SFTP_FAILURE or SFTP_SUCCESS, the category is changed to Acquisition (the first in the list). If you edit one of these notices, the category is changed and the notice isn't sent anymore (the notice is not find in the category commanline). To reproduce: - Go to Tools > Notices and slips - Search for SFTP, check that both SFTP_FAILURE and SFTP_SUCCESS are in module "commandline" - Edit notice SFTP_FAILURE and save some changes in the template - Search for SFTP, check that SFTP_FAILURE now is in module "Acquisition" To test sending the email, you need to have access to an sftp (or to update the script to skip sftp actual action and only keep email reporting, you might need to set manually some value). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43853] New: Allow Templatye Toolkit for SFTP_SUCCESS and SFTP_FAILURE
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43853 Bug ID: 43853 Summary: Allow Templatye Toolkit for SFTP_SUCCESS and SFTP_FAILURE Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- Currently the SFTP_SUCCESS and SFTP_FAILURE notices do not properly call the sftp_status object into the notice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43855] New: Port default SFTP_SUCCESS and SFTP_FAILURE notice to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43855 Bug ID: 43855 Summary: Port default SFTP_SUCCESS and SFTP_FAILURE notice to Template Toolkit syntax Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 Marion Durand <marion.durand(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |43855 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43855 [Bug 43855] Port default SFTP_SUCCESS and SFTP_FAILURE notice to Template Toolkit syntax -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43854] New: Support the other SIP messages in the SIP2 message tester
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43854 Bug ID: 43854 Summary: Support the other SIP messages in the SIP2 message tester Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 43848 Target Milestone: --- Bug 42769 added a tool to the staff interface that runs a SIP2 message through the real SIP handlers and shows the response the account would generate. It supports five messages: patron status, patron information, item information, checkout and checkin. Bug 43848 moves the request parsing, the request building and the session setup out into shared code, used by the SIP server, the SIP command line emulator and the tester. This bug adds the other messages a terminal sends, so that the tester can be used to check a whole SIP flow and not only the first few messages of one: - Hold (15) - Renew (29) - Renew all (65) - Fee paid (37) - Block patron (01) - Patron enable (25) - End patron session (35) - Item status update (19) - SC status (99), whose response (ACS status) describes what the account allows Login (93) and request ACS resend (97) are left out, the tester does not authenticate and has no session to resend. What each message needs: - The request builders. The emulator already has hold, renew and fee paid. The rest are added to Koha::SIP2::RequestBuilder, and the emulator can use them too. - A form with the fields the SIP2 specification gives that message, as the first five have, and the same raw request box. - Response breakdown. The tester splits a response into its fixed part and its fields using the length of the fixed part of each response, which has to be known for each new response. - The same checks as the first five. Any patron or item that a request names has to be one the user may see (library restrictions, IndependentBranches), including the new places they can appear, such as the title of a hold. A patron password is never checked, GOOD or BAD says what it should be, for every message that carries one. - The same isolation. Like a checkout, these change data, which is rolled back, and the things a rollback does not undo are kept out the same way. Hold, renew and fee paid also queue notices and run plugin hooks, which needs a look. Something to decide here, because the point is to test a flow: every message runs in its own transaction that is rolled back, so a hold cannot be followed by a checkin that sees it. An option to run several messages in one transaction, rolled back at the end, would make a flow testable. It could be this bug or a bug of its own. Test plan: 1. Apply the patches of bug 42769, of bug 43848 and then of this bug 2. Open a SIP2 account in the staff interface and use "Test SIP2 messages" 3. For each new message type, fill in the form and run it, and check that the response is the one the SIP server gives for the same request (compare with misc/sip_cli_emulator.pl against a SIP server if you like) 4. Check that a patron or an item you may not see is refused for each message, and that a real patron password is refused 5. Run prove t/db_dependent/Koha/SIP2/ t/db_dependent/api/v1/sip2_account_test_message.t 6. Sign off :-D Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43848 [Bug 43848] Share SIP request parsing and building between server, emulator and tester -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42769] New: Add a SIP testing tool to the staff web interface
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42769 Bug ID: 42769 Summary: Add a SIP testing tool to the staff web interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Now that the SIP configuration is mostly in the staff interface, it would be very useful to have a tool not for testing SIP connectivity, but for checking the response value for the various custom template fields we have. I'm imagining a tab within the account editor ( for saved accounts ) where we can enter things like patron and item barcodes to test the generated response. It would be even better if we could wrap that in a transaction so it doesn't actually do anything, but I have the feeling that may prove infeasible. Such a testing tool would eliminate the need for someone to know the password for the SIP account in order to develop and test the various templates and options for that account. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 41129] New: Migrate place_booking.js to a Vue island.
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 Bug ID: 41129 Summary: Migrate place_booking.js to a Vue island. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Since the bookings functionality requires a significant amount of reactivity due to many interdependent inputs to achieve a good UX, this bug is intended to deprecate place_booking.js in favor of a Vue island that makes this much easier. The goal here is to have a Vue based component that is used for the Staff Interface as well as the OPAC to avoid duplication and diverging implementations and also makes it easier to keep track of problems that then don't need to be fixed in two places. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 305