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

[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

[Bug 37652] New: Add alert for upcoming bookings at checkin
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37652 Bug ID: 37652 Summary: Add alert for upcoming bookings at checkin Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We currently alert at checkout if an item would be required for a booking during the proposed loan period.. We should also alert at check-in for upcoming bookings so the item can be put to one side or marked as ready for collection by the patron who booked the item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42907] New: Add db indexes borrowers.lastseen
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42907 Bug ID: 42907 Summary: Add db indexes borrowers.lastseen Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Add db indexes borrowers.lastseen This would help with SQL reporting when looking very large datasets. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31897] New: New hook when indexing with Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31897 Bug ID: 31897 Summary: New hook when indexing with Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org This patch adds a new hook "before_index_action" with the action "update". This is run on the array reference to the biblio records that are about to be updated in the Elasticsearch index. With this, a plugin can change the record so that it better suits the index without having to change the actual record in the database (something that might be prohibited or discouraged due to centralised cataloging). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 37680] New: inconsistencies with the search results when selecting the "Limit to records with available items" option
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37680 Bug ID: 37680 Summary: inconsistencies with the search results when selecting the "Limit to records with available items" option Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 42740] New: Suggestion status is not kept when editing a suggestion
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42740 Bug ID: 42740 Summary: Suggestion status is not kept when editing a suggestion Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Make a purchase suggestion. 2. Set the status to something, anything. 3. Edit that suggestion, notice that the "Status:" is set to 'No Status' 4. Now when you save, they actual status is lost. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 41579] New: Tidy kohaTable block - suggestions
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41579 Bug ID: 41579 Summary: Tidy kohaTable block - suggestions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 41546] New: Cannot unarchive suggestions
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41546 Bug ID: 41546 Summary: Cannot unarchive suggestions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33430 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33430 [Bug 33430] Use REST API for suggestions tables -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 39514] New: If one basket has uncertain prices, all basket are displayed in red
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39514 Bug ID: 39514 Summary: If one basket has uncertain prices, all basket are displayed in red Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Acquisitions 2. Click 'Search' in the vendor search 3. Click 'Add to basket' next to 'My basket' 4. Click 'From a new (empty) record' 5. Fill out the form - Title: enter a title - Koha item type: choose an item type 5.1. Click 'Add item' - Fund: choose a fund - Uncertain price: check 6. Click 'Save' 7. Go back to Acquisitions 8. Click 'Search' in the vendor search 9. Click 'New' > 'Basket' 10. Enter a basket name 11. Click 'Save' 12. Go back to Acquistions 13. Click 'Search' in the vendor search --> Notice the empty basket is also in bold red, even if it doesn't have uncertain prices 14. Click 'Add to basket' --> Notice everything is in bold and some in red -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 41427] New: Terminology : branch should be library in FilterSearchResultsByLoggedInBranch
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '26

25 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41427 Bug ID: 41427 Summary: Terminology : branch should be library in FilterSearchResultsByLoggedInBranch Initiative type: --- Sponsorship --- status: 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The term "library" is preferred to "branch" in the staff interface https://wiki.koha-community.org/wiki/Terminology#B Bug 37883 introduced a new system preference with "branch". FilterSearchResultsByLoggedInBranch : Don't/Do add a filter to the location column on staff interface search results to filter items by the logged in user branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22