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

[Bug 31046] New: Floating Rules Based on Collection/Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31046 Bug ID: 31046 Summary: Floating Rules Based on Collection/Shelving Location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com PCCLD would like an option for floating rules to be based on the items shelving location or collection. This is how it would work. 1. A system preference allows for an Authorized Value/Shelfing Location or Collection to restrict floating. 2. The Western Research (Library A) location is added to the system preference and all material with the value does not float. 3. Item is cataloged with the Western Research shelving location. 4. Item is checked-out by a user at Library A. 5. The item is returned to Library B. 5. A message appears in Koha stating the item needs to return to Library A because it does not float. -Daniel -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 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 41767] New: Plack backlog parameter
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41767 Bug ID: 41767 Summary: Plack backlog parameter Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The default request backlog for starman is 1024 request wich seems too large for Koha. When the system is overloaded it will typically take several minutes to recover because of the backlog of mostly stale requests. I suggest we set a much lower default value and expose a configuration parameter. I propose $PLACK_WORKERS * $PLACK_MAX_REQUESTS / 2 as a default value (just guessing). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39422] New: Checkout 'remember for session' override does not handle holds cancellation
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39422 Bug ID: 39422 Summary: Checkout 'remember for session' override does not handle holds cancellation Change sponsored?: --- 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - Place several holds for patron A 2 - Checkout one of the items to Patron B 3 - You get a warning with an option to cancel the hold 4 - Check the cancel button and the remember button 5 - Checkout the rest of the held books 6 - No warnings 7 - Check patron A - only the first hold was cancelled We have situations where a caregiver or relative will pickup the holds for a patron and the libraries would like to see all of the holds cancel - i.e. we need to remember the saved options correctly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37638] New: Link permissions to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37638 Bug ID: 37638 Summary: Link permissions to entry in the manual Change sponsored?: --- 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: lauren_denny(a)sil.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to bug 37624, create a link by the permission that takes you to the manual. If applicable, it would also be helpful to put a note by the permission if a system preference is required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5