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

[Bug 12757] Integers in saved SQL report ODT export prepended with single quote
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 --- Comment #7 from David Nind <david(a)davidnind.com> --- Created attachment 200446 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200446&action=e… Bug 12757: Set float type on OpenDocument cells Test plan: 1. Navigate to Reports > Create from SQL. 2. Create a new report with a name and the following SQL query: SELECT 'test', 1, '2' 3. Run the report. 4. Under the Download dropdown, select "Open Document Spreadsheet". 5. Verify a ".ods" file is downloaded. 6. Open the downloaded spreadsheet. 7. Verify the two number-like columns are handled as such. This depends on your choice of spreadsheet software: - In Excel, the numbers should not have a leading single quote in the edit-bar when selected. - In Google Sheets, the numbers should be right-aligned, and selecting both of them should display their sum in the bottom toolbar. 8. Run `prove t/Koha/Util/OpenDocument.t` and verify all tests were successful. Sponsored-by: Open Fifth Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12757] Integers in saved SQL report ODT export prepended with single quote
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200338|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12757] Integers in saved SQL report ODT export prepended with single quote
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42793] New: Add a "Last search" link to staff interface header (similar to "Last patron")
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42793 Bug ID: 42793 Summary: Add a "Last search" link to staff interface header (similar to "Last patron") Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbaker(a)aclsys.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Description of the feature: In the staff interface, we currently have a very useful "Last patron" link in the header that allows staff to quickly jump back to the record they were just working on. I would like to request a similar "Last search" link. Why this is needed: Library staff frequently have to navigate away from a search results page to answer a quick question or check an item in. Having a "Last search" shortcut in the top header would save desk staff significant time and clicks by letting them instantly jump back to their last active catalog or patron search, rather than having to re-type the query or spam the browser's back button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42791] New: Automatic holds on records created with Fast-Add framework
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42791 Bug ID: 42791 Summary: Automatic holds on records created with Fast-Add framework Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl A library would like a process to automatically create holds for items/records that have been created with a Fast-Add framework. The records do display a note when items are checked-in to send to cataloging, but the circulation staff tend to bypass the message on the screen and the items are shelved. If the items are placed on hold, then a hold slip is printed and that is much harder to ignore. While the library could periodically add holds manually, an automated process would be much easier. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42842] New: Remove materialized patron data from tmp_holdsqueue
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42842 Bug ID: 42842 Summary: Remove materialized patron data from tmp_holdsqueue 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: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42503 Target Milestone: --- Since bug 42503 converted the holds queue page to be API-driven, the materialized patron fields in tmp_holdsqueue (surname, firstname, phone, cardnumber) are no longer used. The page now embeds patron data via the borrowernumber FK through the REST API. These columns should be removed because: 1. They are dead code â nothing reads them after bug 42503 2. They leave patron PII (name, phone, card number) in an unaudited table that is not subject to patron data cleanup/anonymization routines 3. Privacy concern: tmp_holdsqueue is rebuilt periodically but retains patron information between rebuilds, and this data is not covered by GDPR/privacy cleanup tools The fix should: - Remove surname, firstname, phone, cardnumber columns from tmp_holdsqueue - Stop populating them in C4::HoldsQueue::CreatePicklistFromItemMap - Update Koha::Schema::Result::TmpHoldsqueue - Remove the undef mappings in Koha::Hold::HoldsQueueItem::to_api_mapping Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 [Bug 42503] Render the holds queue using the REST API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[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 15 Jun '26

15 Jun '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 4

[Bug 29739] New: Add a staff counterpart for OPACURLOpenInNewWindow
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29739 Bug ID: 29739 Summary: Add a staff counterpart for OPACURLOpenInNewWindow Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The OPAC XSLTs respect pref OPACURLOpenInNewWindow when opening URLs. Would be nice to have something like StaffURLOpenInNewWindow in staff? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Jackie U <jackie.usher(a)westsussex.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jackie.usher(a)westsussex.gov | |.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29800] New: Add option to calculate fines when an item is marked lost
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29800 Bug ID: 29800 Summary: Add option to calculate fines when an item is marked lost Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have the system preferences CalculateFinesOnReturn and CalculateFinesOnBackdate to make Koha calculate overdue fines as an item is returned, either in place of or in addition to the fines cron. However, if one marks an item as lost and has MarkLostItemAsReturned enabled, the issue will be ended without an overdue fine being calculated. We should add the option to calculate an overdue fine at the moment of marking an item lost. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15