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

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20989] New: Hold Notes to be added later
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20989 Bug ID: 20989 Summary: Hold Notes to be added later Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently it is only possible to add a Hold Note at the time of creating the hold. It would be nice if notes could be added at a later stage. A few of our customers have asked for this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 40826] New: nbofuser not incremented when using a mana report
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40826 Bug ID: 40826 Summary: nbofuser not incremented when using a mana report Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: elias.lorgnier(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: alex.arnaud(a)biblibre.com When importing a report from mana, the nbofuser dosen't go up as it should. By looking at the code, I think that feature is not implemented, even though the function Koha::SharedContent::increment_entity_value, wich works for subscriptions is implemented. It is simply never used with reports. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 15279] Deprecate bespoke syntax for Slips and Notices
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15279 Paul Derscheid <paul.derscheid(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid(a)lmscloud.de -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21781] New: message_transport_type should allow fallbacks
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21781 Bug ID: 21781 Summary: message_transport_type should allow fallbacks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Bug 21241 adds the ability for a fallback from email to sms when a patron email address isn't found on the suggestions notices. This shouldn't be limited to suggestions, but be a more comprehensive piece of work to capture other hard coded message transports. opac/svc/checkout_notes opac/opac-issue-note.pl opac/opac-memberentry.pl opac/opac-shareshelf.pl circ/pendingreserves.pl circ/article-request-slip.pl C4/Reserves.pm C4/Acquisition.pm misc/cronjobs/automatic_renewals.pl misc/cronjobs/membership_expiry.pl misc/cronjobs/stockrotation.pl Koha/ArticleRequests.pm Koha/Patron/Password/Recovery.pm Koha/Account.pm All of the above have a message_transport_type hard coded to some degree.. some may be better served left as is.. but many would benefit from a fallback. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 40799] New: Loading spinner not removed because .cover-slider is now used instead of .cover-slides
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40799 Bug ID: 40799 Summary: Loading spinner not removed because .cover-slider is now used instead of .cover-slides Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org After Bug 32642, the spinner on cover images is hidden by verify_cover_images() which removes the .cover-slides class from the cover container. However, Bug 33848 modified the SCSS so that the spinner is now triggered by .cover-slider instead of .cover-slides. As a result, the spinner is never removed, because verify_cover_images() only removes .cover-slides. Test plan 1- Follow the test plan from Bug 32642. ==> The spinner is displayed and never disappears. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #234 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- > which includes dropdown select / scroll behaviour improvements :D ----- > I'll be taking a look at the failing cypress tests as well. Thanks, it's very handy we can have UI tests due to being done with Vue ^^ ------ I forgot there was also this failure in the lower level tests: t/db_dependent/Overdues.t .. 8/19 # Looks like you planned 19 tests but ran 9. I don't know if that's just the expected change from the removed tests or if there is an actual issue. -------- > Inserting :undef: default most frequent delay for overdue_1: > Inserting :undef:undef default most frequent notice for overdue_1: > Inserting :undef:undef default most frequent mtt for overdue_1: About this output, at first I though there where issues of undef variables. Like with the uninitialized values earlier reports. , does "all" fits better than undef? I picked it from the circulation rules page but maybe it doesn't have the same meaning? It's only about not scaring an admin about the update having an issue. -------- I tried on main to add two default actions and one action on a specific library. So 3 records in overduerules tables. And the update output is Inserting :J: overdue_1_delay: 2 Inserting :J: overdue_1_notice: AR_COMPLETED Inserting :J: overdue_1_restrict: 1 Inserting :J: overdue_1has_rules: 1 Inserting :J: overdue_2_delay: 6 Inserting :J: overdue_2_restrict: 1 Inserting :J: overdue_2has_rules: 1 Inserting :J: overdue_3_delay: 9 Inserting :J: overdue_3_notice: AR_CANCELED Inserting :J: overdue_3_restrict: 1 Inserting :J: overdue_3has_rules: 1 Inserting :HB: overdue_1_delay: 2 Inserting :HB: overdue_1_notice: ACCOUNT_DEBIT Inserting :HB: overdue_1_mtt: email,print Inserting :HB: overdue_1_restrict: 1 Inserting :HB: overdue_1has_rules: 1 Inserting :HB: overdue_2_delay: 5 Inserting :HB: overdue_2_notice: ACCOUNT_WRITEOFF Inserting :HB: overdue_2_mtt: email,print Inserting :HB: overdue_2_restrict: 1 Inserting :HB: overdue_2has_rules: 1 Inserting :HB: overdue_3_delay: 6 Inserting :HB: overdue_3_notice: PREDUEDGST Inserting :HB: overdue_3_mtt: email,print Inserting :HB: overdue_3_restrict: 1 Inserting :HB: overdue_3has_rules: 1 Inserting :undef: default most frequent delay for overdue_1: Inserting :undef:undef default most frequent notice for overdue_1: Inserting :undef:undef default most frequent mtt for overdue_1: Inserting :undef:undef default most frequent restrict for overdue_1: 0 Inserting :undef:undef default has_rules for overdue_1: 1 Inserting :undef: default most frequent delay for overdue_2: Inserting :undef:undef default most frequent notice for overdue_2: Inserting :undef:undef default most frequent mtt for overdue_2: Inserting :undef:undef default most frequent restrict for overdue_2: 0 Inserting :undef:undef default has_rules for overdue_2: 1 Inserting :undef: default most frequent delay for overdue_3: Inserting :undef:undef default most frequent notice for overdue_3: Inserting :undef:undef default most frequent mtt for overdue_3: Inserting :undef:undef default most frequent restrict for overdue_3: 0 Inserting :undef:undef default has_rules for overdue_3: 1 Inserting FFL:undef: default most frequent delay for overdue_1: 1 Inserting FFL:undef:undef default most frequent notice for overdue_1: AR_CANCELED Inserting FFL:undef:undef default most frequent mtt for overdue_1: email Inserting FFL:undef:undef default most frequent restrict for overdue_1: 1 Inserting FFL:undef:undef default has_rules for overdue_1: 1 Inserting FFL:undef: default most frequent delay for overdue_2: 2 Inserting FFL:undef:undef default most frequent notice for overdue_2: PREDUEDGST Inserting FFL:undef:undef default most frequent mtt for overdue_2: email Inserting FFL:undef:undef default most frequent restrict for overdue_2: 1 Inserting FFL:undef:undef default has_rules for overdue_2: 1 Inserting FFL:undef: default most frequent delay for overdue_3: 3 Inserting FFL:undef:undef default most frequent notice for overdue_3: ODUE Inserting FFL:undef:undef default most frequent mtt for overdue_3: email Inserting FFL:undef:undef default most frequent restrict for overdue_3: 1 Inserting FFL:undef:undef default has_rules for overdue_3: 1 Does anyone know that are expectable sizes of the overduerules table with a large network of libraries? Because even without much per-library specific rules, the output of this bug might be much longer than the rest of the upgrade and flood it. While still being very useful here to test and review. And eventually investigate issues when production upgrades will happen. Wait, for that, this should do: SELECT * FROM circulation_rules WHERE rule_name LIKE 'overdue\_%'; It's not as nice as with the explicit "frequent delay" but that might be a trade-off. Anyway it depends on how large all the current output can be. -------- > I'm aiming to resubmit by Friday this week. No worries, I hope there won't be too many hurdles. And the stuff about the upgrade output can wait the next round of patch revisions, actual testing doesn't depend on it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38627] New: Add pipelines support to Koha
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38627 Bug ID: 38627 Summary: Add pipelines support to Koha Change sponsored?: --- 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have lots of scripts and tools available to us on the Koha server, however many of these have no staff side UI and many of them work in combinations one after the other. It would be great to have a pipeline management tool to allow certain actions to trigger various tasks and have the successful completion of one task trigger the execution of the next task in a pipeline, likely one that uses the output of the previous task. An obvious use case is runreport.pl followed by a file transfer or email etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 22740] New: Automatically change lost status when item is paid for
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22740 Bug ID: 22740 Summary: Automatically change lost status when item is paid for Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: mfuerst(a)hmcpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When patrons pay for a lost item, our staff change the Lost status of the item from "Lost" or "Long overdue Lost" to "Lost and Paid For." This helps make distinctions in reports and in other workflows. With the advent of online payment options (PayPal), it adds what feels like extra work for us to hunt down these items and make this change. In both cases it would be beneficial if paying for an item resulted in the item's Lost status being changed to a specified authorized value. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 41731] New: Automate change Withdrawn status when item is written off
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41731 Bug ID: 41731 Summary: Automate change Withdrawn status when item is written off Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41730 Bug 41730 replicates the UpdateItemLostStatusWhenPaid functionality but for withdrawn status. We should probably offer the same for when a lost fee is written off, comparable to UpdateItemLostStatusWhenWriteOff. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41730 [Bug 41730] Automate change Withdrawn status when item is paid for -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0