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

[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 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

[Bug 37408] New: Update description of UpdateItemLostStatusWhenWriteOff and UpdateItemLostStatusWhenPaid to link to authorised value
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37408 Bug ID: 37408 Summary: Update description of UpdateItemLostStatusWhenWriteOff and UpdateItemLostStatusWhenPaid to link to authorised value Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Similar to Bug 27753 it would be nice if these link to the LOST value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22312] New: BlockReturnOfLostItems does not prevent lost items filling holds
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22312 Bug ID: 22312 Summary: BlockReturnOfLostItems does not prevent lost items filling holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When the preference BlockReturnOfLostItems is set, it prevents checkin from checking the item in, but it does not prevent prompting to fill a hold with that item. Steps to reproduce: 1. Set BlockReturnOfLostItems to Block 2. Place a hold that can be filled by a particular item 3. Mark that item as Lost (or Missing, or any other flavor of lost) 3. Attempt to check in that item Expected results: Message stating that "Item is lost, cannot be checked in./Cannot check in/NOT CHECKED IN", no message about the hold. Actual results: The "Item is lost, cannot be checked in./Cannot check in/NOT CHECKED IN" message displays in the page, but is quickly covered by the popup saying that it can fill a hold. If any of the Confirm buttons (Confirm, Confirm and print slip, Confirm and transfer) is clicked in the hold popup, when the popup closes the message in the page below is removed, leaving no sign that the hold was just filled by an item which is now both being held and also lost. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28896] New: Checkin Slip doesn't work for anonymized checkouts
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28896 Bug ID: 28896 Summary: Checkin Slip doesn't work for anonymized checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The new CHECKINSLIP notice does not work on patrons whose checkouts are anonymized upon checkin. Instead it appears that the patron had no checkins at all! This is due to how the feature gets the old issues. The printslip script takes the borrowernumber and a branchcode and searches the old_issues table which is then filtered by date. I think for this to function for anonymized checkouts we need to pass the actual issue_id's as a list to the slip so they can be looked up directly and not inferred by borrowernumber, branchcode and date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15