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

[Bug 42814] New: Advance notice checkboxes enabled in inactive messaging preferences form
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42814 Bug ID: 42814 Summary: Advance notice checkboxes enabled in inactive messaging preferences form Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 28308 added JavaScript to disable the Advance notice transport checkboxes when "Days in advance" is blank. However, the JavaScript only checks the value of the days select. When the messaging preferences form is inactive/read-only and a non-blank days value is selected, the script removes the disabled state from the checkboxes. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 43110] New: When a patron has a value for advance notices the checkboxes are enabled on the details view
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43110 Bug ID: 43110 Summary: When a patron has a value for advance notices the checkboxes are enabled on the details view Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1 - Edit a patron, set a value for advance notices, do not check any transports 2 - View the details for the patron: http://localhost:8081/cgi-bin/koha/members/moremember.pl?borrowernumber=5 3 - Note the checkboxes are enabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 43086] New: Prefill unauthenticated patron information for new ILL requests if available
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43086 Bug ID: 43086 Summary: Prefill unauthenticated patron information for new ILL requests if available Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: olivia.reynolds(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- If an unauthenticated patron makes multiple ILL requests back-to-back, they have to fill in their patron details every time. Saving and prefilling these details would save time in this case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 28071] New: Ability to batch remove titles from a list
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28071 Bug ID: 28071 Summary: Ability to batch remove titles from a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Sometimes, lists can have a quite large number of titles. With the export option, it's easy to work on this corpus, and, sometimes, find some titles we finally don't want in that list. If they are numerous, it's for now quite painful to find and delete them. A useful option could be, as it exists with the button "Add items", to be able to remove several titles at a time using barcode or biblionumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 22108] New: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22108 Bug ID: 22108 Summary: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When adding titles to a basket from a staged file (acqui/addorderiso2709.pl), item and fund choices can be applied item-by-item on the Select To Import tab or can be applied to all titles at once using the Item Information or Default Accounting Details tabs. However, if the library is using MARCItemFieldsToOrder to pull some of these values from vendor-supplied MARC files, Koha will ignore selections made on the Item Information or Default Accounting Details tabs. Nothing in the interface indicates that values selected on those tabs will not be used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 40869] New: Preserve mandatory fields even if hidden when duplicating item
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40869 Bug ID: 40869 Summary: Preserve mandatory fields even if hidden when duplicating item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When item fields are mandatory, which usually indicate they are somehow critical for functionality and expected to exist in Koha, it makes sense they should be preserved when duplicating an item, even if the field is hidden. Right now hidden fields are ignored using the "ignore_invisible_subfields" option in the form builder for item. If for current library (holding branch) is hidden (which is the case for our library), the biblio page will crash after duplicating an item, which now has a missing holding branch. Fixing this is simple by adding a check for the mandatory attribute in the check for "ignore_invisible_subfields" (I also renamed this option to "ignore_non_mandatory_invisible_subfields" for clarity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 37441] New: Sometimes images don't upload in Uploads Tool
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37441 Bug ID: 37441 Summary: Sometimes images don't upload in Uploads Tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.noel(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The file upload tool intermittently fails, causing the selected file to disappear without uploading. The second time we want to upload, it will work. Replicate: 1. Go to Tools > Uploads 2. Click "Choose file" and select any file (png, jpeg, pdf...) 3. Click "Upload" -> The file uploads successfully 4. Click "Delete" to remove the uploaded file. -> The page returns to the upload screen. Repeat steps 2 and 3. -> The selected file is deleted, and is not uploaded, requiring the process to be restarted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

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