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

[Bug 41705] New: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Bug ID: 41705 Summary: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: black23(a)gmail.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, lisette(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, maryse.simard(a)inlibro.com, testopia(a)bugs.koha-community.org Depends on: 23228, 23461 Blocks: 13985 The pattern we use for automatically printing receipts and slips can often trigger popup blockers. This is because we trigger the popup window via JavaScript after page reload and this is interpreted as not being a user directed event and thus invokes many browsers popup blocking code. We could reverse our process such that the form submission itself has a target="_blank" attribute to trigger the popup at form submission time (which is a direct user action), then our controller handles the post, redirect, get pattern for printing. We fires the window print in the already opened new tab and finally close the tab, thus bringing the original tab back into focus, after print. This would need a little thought regarding the original tab, as we'd need the reset that tabs context/state as part of the initial submit that triggers the popup earlier in the process. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] [Omnibus] Cash Management - Koha as 'Point of Sale' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 [Bug 23228] Add option to automatically display payment receipt for printing after making a payment https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23461 [Bug 23461] Popup blockers triggered by option to automatically display payment receipt for printing after making a payment -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug. You are the assignee for the bug.

1 54

[Bug 42835] New: ElasticSearch should have an items index
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 Bug ID: 42835 Summary: ElasticSearch should have an items index Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 134

[Bug 41294] New: Data not available for certain months should not result in a complete failure of the harvest
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41294 Bug ID: 41294 Summary: Data not available for certain months should not result in a complete failure of the harvest Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk I don't know if it's related to the SUSHI protocol itself (in that case there is nothing to do...) or to Koha, but it's annoying. Ex : for a data source if you try to harvest march and april 2025, and april data are not available, the harvest will fail with this error : Sushi harvesting return an error if some months are not available : Usage Not Ready for Requested Dates - Usage not yet released for the following yearmonths(s): 202504 3031 -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 30557] New: Add ability to create Item lists
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30557 Bug ID: 30557 Summary: Add ability to create Item lists Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is relevant for multi-branch installations. Lists currently appear to be primarily bibliographic lists. This creates a problem when sorting lists by call number. In this scenario there may be multiple items from different libraries using different call number schema attached to a single bibliographic record. The list cannot be sorted accurately by call number. It would be helpful if there was an option for an item based list. In this scenario items are added to a list for a specific branch. The call number sort will then sort correctly because the call number schema will be consistent for the branch. An item list would display the same information as a bibliographic list with the exception of additional branches which may also have the item. A typical use case would a library creating an item list, sort by call number, and then use that list to go to the shelf to pull the items in order. This is currently not possible in a multi-branch installation without a bit of work. It would require downloading the list and then cleaning up the list to be useful for this kind of work. It may be possible to create a report that will do this, but it would be a nice added functionality in the List tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 273

[Bug 42217] New: ERM Usage – Harvesting Twice Does Not Overwrite Data
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42217 Bug ID: 42217 Summary: ERM Usage – Harvesting Twice Does Not Overwrite Data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk If reports are harvested more than once, the usage_count should be overwritten when the data has changed. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 41249] New: ILL batches should be compatible with AutoILLBackendPriority
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41249 Bug ID: 41249 Summary: ILL batches should be compatible with AutoILLBackendPriority Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(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 AutoILLBackendPriority suggests the top most available backend in priority when creating a new ILL request. This should also work the same when creating requests through the ILL batches functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 40575] New: Transferring order will reload the page and its form
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40575 Bug ID: 40575 Summary: Transferring order will reload the page and its form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Test plan: 1 - Create two baskets: "Source Basket" and "Dest Basket" 2 - Add one command line to "Source Basket" 3 - Close the basket 4 - Receive shipment 5 - Receive order 6 - Cancel the order receive 7 - Transfer the order to the Dest Basket -> When clicking on chose, you will be asked if you want to send again infos (which were sent to cancel the order receive), and if accepting, you will be printed an error. 8 - Apply patch 9 - Repeat the process with another source Basket and notice the page is simply reloaded without sending form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42720] New: Add REST API equivalents for svc/report and opac/svc/report
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42720 Bug ID: 42720 Summary: Add REST API equivalents for svc/report and opac/svc/report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have equivalent functionality as svc/report in the REST API. Perhaps some time in the future we could deprecate the old version. Having a REST equivalent would come with better better authentication, documentation, http responses ( somewhat fixed by bug 42596 ) and other things. It could have pagination for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42646] New: ModSuggestion: SMS status-change notices always contain email template content
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42646 Bug ID: 42646 Summary: ModSuggestion: SMS status-change notices always contain email template content Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org In C4/Suggestions.pm, ModSuggestion() selects the transport type (email or sms) at ~line 253 and stores it in $transport, but then calls GetPreparedLetter() at ~line 256 without passing message_transport_type. GetPreparedLetter() defaults message_transport_type to 'email' when the parameter is absent (C4/Letters.pm ~line 585), so it always fetches the email template variant of the notice â even when $transport was resolved to 'sms'. The result is that any patron who legitimately receives an ACCEPTED/AVAILABLE/REJECTED/ORDERED/CHECKED notice via SMS receives the email-formatted body text rather than the SMS-specific template content. Related to: Bug 39984, Bug 42645 Test plan: 1. Configure SMSSendDriver and a patron with smsalertnumber but no email. 2. Enable FallbackToSMSIfNoEmail. 3. Create SMS-specific templates for the ACCEPTED notice code (Notices > ACCEPTED > SMS tab). 4. Submit a suggestion as that patron and accept it. 5. Check the message_queue table: the content column will contain the email template body, not the SMS template body. 6. Apply patch (add message_transport_type => $transport to the GetPreparedLetter() call in ModSuggestion). 7. Repeat: the content column now contains the SMS template body. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 42809] New: Notification falls to print back when two messaging preferences are set but only one is valid.
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Bug ID: 42809 Summary: Notification falls to print back when two messaging preferences are set but only one is valid. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960#c18 This [Bug 40960] causes problem for patrons with their messaging preferences set to receive both sms and mail and one of the transport types fails. For example when the patron does not have a mail registered but both message types are checked on their account they will receive both sms and printed notices. When using standard/pre-filled messaging preferences based on patron category this can create a large number of unwanted print notices. When a notice is sent with sms OR mail you don't want to create a print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29