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 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 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 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 43091] New: Staff-only Vue island chunks are emitted into the OPAC dist directory
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43091 Bug ID: 43091 Summary: Staff-only Vue island chunks are emitted into the OPAC dist directory Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: paul.derscheid(a)lmscloud.de Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Blocks: 41129 Target Milestone: --- The intranet and OPAC islands builds share the same entry point, koha-tmpl/intranet-tmpl/prog/js/vue/modules/islands.ts, which hardcodes every island in its componentRegistry. The islandsExport() factory in rspack.config.js (introduced by bug 26355) only varies the output path per application, so the OPAC compilation emits a lazy chunk for every registered island into koha-tmpl/opac-tmpl/bootstrap/js/vue/dist/: - acquisitions-menu.[hash].esm.js - vendor-menu.[hash].esm.js - admin-menu.[hash].esm.js On top of that, the OPAC islands.esm.js bundles the staff-side Pinia stores (main, navigation, vendors) because hydrate() imports them unconditionally. These chunks are never executed on the OPAC. hydrate() only fetches a chunk when a matching custom element is present in the DOM, and no OPAC template renders one, so this is not a security issue in itself. But it publishes staff-interface code unauthenticated in the OPAC docroot, wastes build output, and is a leak channel by construction: any future staff-side island whose bundle contains something sensitive would land in the public web root by the same mechanism. The attached patch splits modules/islands.ts into shared machinery and per-application entry points (islands-intranet.ts, islands-opac.ts). Each entry declares its islands as a Map literal and feeds it through registerIsland(), so core islands take the same registration path as plugin islands (bug 42150), and passes its store definitions into hydrate() instead of the shared module importing every store. The plugin import surface of islands.esm.js (registerIsland, hydrate, the Vue re-exports used by the import map) is preserved on both entries via star re-exports. After the patch, the OPAC dist contains only islands.esm.js and the patron-self-renewal chunk. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 [Bug 41129] Migrate place_booking.js to a Vue island. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 43848] New: Share SIP request parsing and building between server, emulator and tester
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43848 Bug ID: 43848 Summary: Share SIP request parsing and building between server, emulator and 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: 42769 Target Milestone: --- Bug 42769 adds a tool to the staff interface that runs a SIP2 message through the real SIP handlers (Koha::SIP2::MessageTester). To do that it has to parse a request and build a server context the way the SIP server does, and build requests the way a terminal does. All of this is currently buried in code that also does something else, so each caller ends up with its own copy: - C4::SIP::Sip::MsgType::handle both parses a request and answers it. - C4::SIP::Sip::MsgType::login_core both authenticates a terminal and builds the account, institution, policy and ILS connection it works with. - misc/sip_cli_emulator.pl builds every request a terminal sends, but as subs inside a script, so nothing else can use them. This bug pulls the shared parts out, so the SIP server, the SIP command line emulator and the SIP2 message tester use the same code: - MsgType::parse_message: the part of handle() that sets the field delimiter, checks and removes the error detection suffix and splits a message into fixed and variable length fields. handle() calls it, a caller that only wants the parsed message can get it without anything being printed. - MsgType::build_session: what login_core does once a terminal has authenticated. login_core calls it. - Koha::SIP2::RequestBuilder: the request builders of the emulator, now shared by the emulator and the message tester. - The message tester then reads a request exactly as the handler does (error detection suffix, checksum) and builds requests with the shared builders. There is no change in behaviour for the SIP server. Two small fixes to the emulator come with the move: the item information request carried a language field that the server's template for that message does not have (so the institution field was lost), and a field value of 0 was sent as an empty value. The new tests build each request and have the SIP server's own parser read it back. Test plan: 1. Apply the patches of bug 42769 and then the patches of this bug 2. Run prove t/db_dependent/SIP/ t/SIP/ t/Koha/SIP2/ t/db_dependent/Koha/SIP2/ t/db_dependent/api/v1/sip2_account_test_message.t 3. Confirm that all tests pass 4. Optionally run misc/sip_cli_emulator.pl against a SIP server (-a host -p port -su user -sp password -l institution --patron X --item Y -m patron_status_request -m patron_information -m item_information -m checkout -m checkin) and confirm login and every message still gets a response, and that the item information response names the institution 5. Sign off :-D Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42769 [Bug 42769] Add a SIP testing tool to the staff web interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6