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

[Bug 9598] Ability to split up shipping cost between all items and funds on an invoice
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9598 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9589] Authorities to authorities linker
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9589 --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Thea Anne from comment #4) > This is still a problem. My library has upgraded from a very ancient edition > of KOHA & I am sorely missing this ability. Was this something that was developed for you in your previous version and that got lost in the update? Wondering as I am not aware Koha had this feaure before (at least since 3.2) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42918] New: SRU-Abfrage in Deutscher Nationalbibliothek liefert keine Treffer.
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42918 Bug ID: 42918 Summary: SRU-Abfrage in Deutscher Nationalbibliothek liefert keine Treffer. Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: holger.voss(a)posteo.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Created attachment 200991 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200991&action=e… 4 Screenshots Despite the correct settings, the DNB does not return any hits in the SRU search or the Z39.50 search. The DNB server is accessible and delivers reliable results via the browser, but not via Koha's query module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 17110] New: Lower CSRF expiry in Koha::Token
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17110 Bug ID: 17110 Summary: Lower CSRF expiry in Koha::Token Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 28703] New: Display problem in 505$a field
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28703 Bug ID: 28703 Summary: Display problem in 505$a field Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hc(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 122798 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=122798&action=e… Appearance of arrows in 505 field Content in the 505$ a field (Formatted contents note) is displaying arrows at the beginning and end of the content. This was not appearing on the 19.11 release of Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 9589] Authorities to authorities linker
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9589 Thea Anne <jezzinelibraryamnq(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jezzinelibraryamnq(a)gmail.co | |m --- Comment #4 from Thea Anne <jezzinelibraryamnq(a)gmail.com> --- This is still a problem. My library has upgraded from a very ancient edition of KOHA & I am sorely missing this ability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40153] New: Add Authen::SASL::Perl as explicit dependency
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40153 Bug ID: 40153 Summary: Add Authen::SASL::Perl as explicit dependency Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In Mattermost Jan Kissig mentioned how Authen::SASL::Perl wasn't automatically installed with Koha on a new server. At a glance libauthen-sasl-perl is just a recommendation of libemail-sender-perl, so if for whatever reason recommendations aren't installed, it will fail to install and Koha won't be able to send SMTP emails. We'll need a newer version of Authen::SASL::Perl for bug 38338 anyway, so may as well make it explicit sooner rather than later. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 20547] New: Add default indicators for authorities (counterpart of 9701)
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20547 Bug ID: 20547 Summary: Add default indicators for authorities (counterpart of 9701) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Bug 9701 adds them at the biblio side. We could do the same for authorities. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 30215] New: "Item found" in accountlines untranslatable
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30215 Bug ID: 30215 Summary: "Item found" in accountlines untranslatable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When a lost item is returned and refunded to the patron, the accountline description contains "Item found" which is untranslatable. To generate this accountline: 0- Make sure BlockReturnOfLostItems is set to Don't Block 0- Make sure WhenLostChargeReplacementFee is set to Charge 0- In Circulation rules, make sure Default lost item fee refund on return policy is set to one of the Refund options 0- Make sure your item has a replacement price (field v of the item) 1- Check out the item to a patron 2- Change the status of the item to lost The patron should be charged the replacement price 3- Check in the item The patron should have a new credit Lost item fee refund In the description of this new credit, it says "Item found <itemnumber>". I couldn't find "Item found" anywhere in the po files. In fact, when I git grep it, it only shows up in C4/Items. (Also, I'm wondering if the itemnumber is really useful here, I think it will confuse library staff as I myself was confused, but this is not the point of this bug) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42432] New: "On hold due date" input on patron checkouts table is ignored when renewing
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42432 Bug ID: 42432 Summary: "On hold due date" input on patron checkouts table is ignored when renewing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com ## Description Bug 7088 introduced an **"On hold due date"** input in the patron checkouts table footer (file: `koha-tmpl/intranet-tmpl/prog/en/includes/checkouts-table-footer.inc`). The input is shown when `AllowRenewalOnHoldOverride` is enabled and the librarian ticks the renew checkbox on any row whose item is on hold for another patron. The intent is that renewals of on-hold items use the value from this input, while non-on-hold renewals use the ordinary "Renewal due date" input. Since Bug 36084 ("svc - renew", Feb 2024, commit `99d776f58e0`), which replaced the `svc/renew` endpoint with a REST API client call, the code that conditionally read the on-hold input was lost. The replaced snippet was: ```js // pre-Bug 36084 var dueDate = isOnReserve ? $("#newonholdduedate input").val() : $("#newduedate").val(); // post-Bug 36084 (current) var dueDate = $("#newduedate").val(); ``` at what is now `koha-tmpl/intranet-tmpl/prog/js/checkouts.js:1041`. The `#newonholdduedate` input is still shown, still mirrored from `#newduedate`, and still flips the `onHoldDueDateSet` flag when edited â but its value is never attached to the `params` object posted to `POST /api/v1/circulation/checkouts/{id}/renewals`. A grep across `*.pl`, `*.pm`, `*.tt`, `*.inc`, `*.js`, `*.yaml` confirms that the form field name `newonholdduedate` (distinct from `renewonholdduedate` used by `circ/renew.pl`) has no consumer. The **Renew** page (`circ/renew.pl`, field `renewonholdduedate`) is unaffected and continues to work. ## Steps to reproduce 1. In a KTD environment, set `AllowRenewalOnHoldOverride = Allow`. 2. Check out item A to patron P1. 3. Place a hold on item A for patron P2. 4. Open P1's Patron details page and scroll to the **Checkouts** table. 5. Tick the **Renew** checkbox on the row for item A. Observe that the **"On hold due date"** input appears in the table footer. 6. In **"Renewal due date"** enter a date two weeks from now (say `2026-05-05`). 7. In **"On hold due date"** enter a clearly-distinct date one month from now (say `2026-05-20`). 8. Click **"Renew or check in selected items"**. 9. Inspect the resulting `issues.date_due` for item A, or observe the value now shown in the refreshed table. ## Expected behaviour `issues.date_due` equals `2026-05-20` (the "On hold due date" value), because item A is on hold. ## Actual behaviour `issues.date_due` equals `2026-05-05` (the "Renewal due date" value). The "On hold due date" value is silently discarded. ## Suggested fix In `koha-tmpl/intranet-tmpl/prog/js/checkouts.js`: - The `renew(item_id)` function (around line 1010) currently takes only the `item_id`. Inside it, look up whether the row is on hold by testing `$("#renew_" + item_id).is("[data-on-reserve]")` (the `data-on-reserve` attribute is already set on the checkbox by the table builder at around line 557). - Around line 1041, restore the conditional: ```js var isOnReserve = $("#renew_" + item_id).is("[data-on-reserve]"); var dueDate = isOnReserve ? $("#newonholdduedate input").val() : $("#newduedate").val(); ``` Keep the existing `if (dueDate && dueDate.length > 0) { params.date_due = dueDate; }` guard so blank values still fall through to the standard loan rule. ## Tests This bug should also introduce regression coverage. There is currently: - No Perl test that exercises `newonholdduedate` form submission. - No Cypress spec covering the on-hold branch of the checkouts-table renewal flow (which is what would have caught the regression in 2024). A Cypress spec under `t/cypress/integration/Circulation/` should: 1. Seed a patron with an on-hold checkout (use existing factories). 2. Visit the patron's checkouts page. 3. Tick the renew checkbox on the on-hold row. 4. Assert the "On hold due date" input is visible. 5. Set distinct dates in "Renewal due date" and "On hold due date". 6. Click "Renew or check in selected items". 7. Assert the refreshed row's displayed due date matches the "On hold due date" value, not the "Renewal due date" value. ## References - Bug 7088 â original feature (commit `c48af49ded4`, 2018) - Bug 36084 â regression point (commit `99d776f58e0`, 2024) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14