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

[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

[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

[Bug 41729] New: Collapsing makes it hard to copy and paste barcodes from moredetail.pl
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41729 Bug ID: 41729 Summary: Collapsing makes it hard to copy and paste barcodes from moredetail.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org Bug 39189 added collapsing sections to moredetail.pl. A lot of libraries were used to being able to easily copy the barcode from this page which has become harder with the collapsing element. It might be helpful to at least add the barcode to the "Item information" section to give an easier place to copy the barcode from on that page. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 7010] Select all records from search
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7010 --- Comment #9 from Owen Leonard <oleonard(a)myacpl.org> --- Someone ought to throw +1 dollars at this if it's so wanted :D -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0