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

[Bug 39643] New: Add flag to delete access files in cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39643 Bug ID: 39643 Summary: Add flag to delete access files in cleanup_database Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries may find it helpful to be able to delete old access files automatically if a flag were added for this purpose in the cleanup_database.pl cron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24035] New: When recording local use, there is no alert for holds
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24035 Bug ID: 24035 Summary: When recording local use, there is no alert for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 One way of recording local use is through a statistical patron. Checking an item out to a statistical patron records a local use but does not actually check the item out. However, if the item is on hold, there is no indication that it is so, since the item doesn't go through the checkout process. But since the staff is already processing the item to scan it for local use, I feel like it would be logical to alert them that there is a hold on this item. To reproduce: 1- Create a statistical patron category 1.1- Go to Administration > Patron categories 1.2- Create a new patron category 1.3- Fill in the code, description and expiry date 1.4- In the 'Category type' field, choose 'Statistical' 1.5- Save 2- Create a patron of that category 3- Place a hold on an item (for another patron) 4- Check out the item to the statistical patron => It says 'Local use recorded' but there is no pop-up saying the item is on hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 36013] New: update_totalissues.pl should not log
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36013 Bug ID: 36013 Summary: update_totalissues.pl should not log Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Even when CataloguingLog is on, misc/cronjobs/update_totalissues.pl should not log the changes. It is useless and takes database space. Do like bulkmarcimport.pl : https://git.koha-community.org/Koha-community/Koha/src/branch/23.11.x/misc/… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 42507] New: Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42507 Bug ID: 42507 Summary: Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 42505 The recall print-slip flow has the same browser popup-blocker problem fixed for hold slips in bug 42505. In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print-recall click handler sets a hidden recall_slip=1 input and submits the form. circ/returns.pl reads that param and sets the recall_slip template variable on the response page. The response page then calls Dopop('/cgi-bin/koha/recalls/recall_pickup_slip.pl?recall_id=...') from \$(document).ready (via 'if (recall_slip) Dopop(...)') â long after the user gesture has expired. Modern browsers block that window.open() as an unsolicited popup. The recall is confirmed but the slip never appears. Reproduction ============ 1. Place a recall on an item (RecallsEnabled etc. configured). 2. Check in the item; the 'Recall found' modal appears. 3. Click 'Print slip and confirm' (the .print-recall button). 4. Expected: recall is confirmed and the recall pickup slip opens in a new window. 5. Actual: the recall is confirmed but the slip popup is blocked by the browser. Suggested fix ============= Mirror the bug 42505 approach: open the recall pickup slip synchronously inside the .print-recall click handler using the recall_id available in the form, so the window.open() remains tied to the user gesture. Then submit the form to confirm the recall. This avoids the document.ready Dopop chain and the popup blocker. Depends on bug 42505 to keep the fixes consistent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 [Bug 42505] Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42506] New: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42506 Bug ID: 42506 Summary: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 42505 With HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do", a check-in that traps a hold for another branch silently confirms the hold and places the item in transit. The hold transfer slip is then meant to open automatically. The slip is opened via Dopop() / window.open() called from $(document).ready on the response page (koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt, near the 'if (print_slip)' block). Because that window.open() runs after a fresh page load and is not associated with a user gesture, modern browsers commonly block it as an unsolicited popup. The hold is confirmed, the item is in transit, but the librarian sees no slip. This is the auto-fill counterpart to bug 42505. Bug 42505 fixes the manual click path by opening the slip synchronously in the .print click handler. The auto-fill path has no click handler to attach to, so it needs a different solution. Possible approaches =================== 1. Render an inline 'Print slip' button (or banner with a button) on the response page when print_slip is set, and let the librarian click it to open the slip. The user gesture then drives window.open() and is not blocked. 2. Render the slip inline on the response page, perhaps inside an iframe, and trigger window.print() from inside that iframe. 3. Stop using window.open() for the slip and switch to a same-window print mechanism using a hidden iframe + content.print(). Reproduction ============ 1. Set HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do". 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. Expected: hold is auto-confirmed, item placed in transit, slip opens in a new window. 5. Actual: hold is auto-confirmed and item placed in transit, but the slip popup is blocked by the browser. Depends on bug 42505 because the chosen approach for one path may inform the other (the manual click fix in 42505 keeps Dopop()/window.open() but moves it inside the gesture; this auto-fill path may need a more fundamental change away from that pattern). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 [Bug 42505] Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 38737] New: Batch item deletion w/delete record broken
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38737 Bug ID: 38737 Summary: Batch item deletion w/delete record broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To reproduce in koha-testing-docker (I started it wirh "ktd --es7 up"): - Find a record with at least one item - Click on "Select all" for the items - Click on "Delete selected items" - Click the checkbox for "Delete records if no items remain." - Click on "Delete selected items" - Click on "View detail of the enqueued job" - The job failed Logs: ==> /var/log/koha/kohadev/worker-output.log <== {UNKNOWN}: An Elasticsearch error occurred during bulk delete at /kohadevbox/koha/Koha/BackgroundJob/BatchDeleteItem.pm line 153. at /kohadevbox/koha/Koha/BackgroundJob/BatchDeleteItem.pm line 177 [2024/12/18 08:55:39] [WARN] Uncaught exception processing job id=9: encountered object '{UNKNOWN}: An Elasticsearch error occurred during bulk delete at /kohadevbox/koha/Koha/BackgroundJob/BatchDeleteItem.pm line 153. at /kohadevbox/koha/Koha/BackgroundJob/BatchDeleteItem.pm line 177 ', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at /kohadevbox/koha/Koha/BackgroundJob.pm line 270. main::catch {...} /kohadevbox/koha/misc/workers/background_jobs_worker.pl (206) The job in the database: MariaDB [koha_kohadev]> select * from background_jobs where id = 9\G *************************** 1. row *************************** id: 9 status: failed progress: 0 size: 4 borrowernumber: 51 type: batch_item_record_deletion queue: long_tasks data: {"delete_biblios":"on","record_ids":["27","24","25","26"]} context: {"number":"51","register_name":null,"shibboleth":"0","branch":"CPL","cardnumber":"42","flags":"1","desk_name":null,"register_id":null,"emailaddress":null,"interface":"intranet","desk_id":null,"surname":"koha","id":"koha","firstname":null,"branchname":"Centerville"} enqueued_on: 2024-12-18 08:55:39 started_on: 2024-12-18 08:55:39 ended_on: NULL 1 row in set (0.000 sec) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 35957] New: Does Serial module still allow saving 0000-00-00 in database?
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35957 Bug ID: 35957 Summary: Does Serial module still allow saving 0000-00-00 in database? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Seeing two issues in 22.11 with invalid/empty date fields: [1] Exception 'Koha::Exceptions::WrongParameter' thrown 'Invalid date '00-1-11-30' passed to output_pref' Crash in output_pref comes from serials/subscription-add.pl line 405 $nextacquidate = $nextacquidate ? output_pref( { str => $nextacquidate, dateonly => 1, dateformat => 'iso' } ) : $firstacquidate; So it received a 0000-00-00. [2] Receive step on serial collection. Save issue without filling dates: | 9531 | 156662 | 318 | No. 12 | 11 | 0 | 0 | 1 | 0000-00-00 | | 0000-00-00 | | NULL | 0 | NULL | Planned and publisheddate were NULL but are now 0000-00-00. Did not check master. Probably still the same? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40151] New: Make SeparateHoldings work again
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40151 Bug ID: 40151 Summary: Make SeparateHoldings work again Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce in KTD: - SeparateHoldings = Separate - Find a record with items from more than one library, for example "The definitive guide to Catalyst" - View the detail page - No items are displayed and the "Processing ..." spinner spins indefinitely -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42411] New: "Place hold" displayed when not possible
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42411 Bug ID: 42411 Summary: "Place hold" displayed when not possible Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com "Hold must be item level" -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42502] New: Tools: Not all loans show the new due date in Batch extend due dates-tool
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42502 Bug ID: 42502 Summary: Tools: Not all loans show the new due date in Batch extend due dates-tool Initiative type: --- Sponsorship --- status: 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: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 198399 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198399&action=e… The due dates are missing from the New due date colum Batch extended due dates-tool Not all searched loans show the new due date in the New Due Date-column. number of search results does not matter, as date can be missing even in a small search result. The smallest search result we saw had only one loan. The tool works and change the due date to the new date, even though the new due date is not displayed in the column. Even if the tool is working correctly, all loans searched for should still show a date in the New Due Date column. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0