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

[Bug 21264] New: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Bug ID: 21264 Summary: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We should test for remains of bug 20461. Which will cause that more items (serial issues) will be created with an itype to NULL See the following for more details about the issue https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461#c13 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 39504] New: Batch record modification 'doesn't exist' condition not checking every matching tag
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39504 Bug ID: 39504 Summary: Batch record modification 'doesn't exist' condition not checking every matching tag Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org I feel like this MARC modification template isn't behaving as I expect it to. I have a biblio record with the following MARC: 700 $a John Smith $e Editor 700 $a Sally Smith I want a template that will add a value in 700$e if 700$e doesn't exist. My MARC modification template action looks like: - Add new field 700$e with value test if 700$e does not exist It doesn't work, probably because the earlier 700 tag does have the $e subfield, so the condition is false and it moves on. I've tried with other variations for the template action, for example - Add new field 700$e with value test2 if 700$e does not match RegEx m/(.*)/ Still doesn't apply, and I think it should be normal to expect that the MARC modification template will look at all 700 tags to apply this action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 38712] New: Order My Lists options alphabetically
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38712 Bug ID: 38712 Summary: Order My Lists options alphabetically 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: chloe.zermatten(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In the top header navigation menu on the Koha OPAC, sets the order of the 'My Lists' dropdown to be sorted alphabetically instead of by modification date. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 36682] New: Replace yarn with pnpm
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36682 Bug ID: 36682 Summary: Replace yarn with pnpm Change sponsored?: --- Product: Koha Version: unspecified 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: me(a)paulderscheid.xyz QA Contact: testopia(a)bugs.koha-community.org The idea is to deprecate yarn in favor of pnpm as it offers - better disk space efficiency - speed (compared to yarn) - deterministic installs - stricter dependency isolation -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 39698] New: Add option to expand responsive datatable rows by default
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39698 Bug ID: 39698 Summary: Add option to expand responsive datatable rows by default Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org kohaTables on the OPAC are currently configured to display a '+' button, when the table is overflowing. When this '+' is clicked, the overflowing cells are displayed on new lines. I propose a system preference that would control whether this button is a '+' or a '-' by default, and thusly, whether the overflowing cells are shown or hidden. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 28863] New: Cancel a Pending Notice
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28863 Bug ID: 28863 Summary: Cancel a Pending Notice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org We would like the ability to cancel any notice that is currently "Pending" on the Notices tab in a user's account. Also, a record of which librarian cancelled the notice and date/time stamp would be very useful. Use Case: Item is discharged, hold is trapped, & notice is generated. Staff then realizes that the item is badly damaged and reverts the hold to obtain another copy. However, the notice for the original item is now Pending in the account and the email will be sent - even though the item is not on the Hold Shelf. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 39631] New: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39631 Bug ID: 39631 Summary: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the system preference OverdueNoticeCalendar is activated, the script longoverdue.pl continues to calculate overdue duration using calendar days instead of working days. This creates a discrepancy with overdue_notices.pl, which correctly uses working days for triggering overdue notices when OverdueNoticeCalendar is enabled. As a result, items may be marked as lost by longoverdue.pl before the final configured overdue notice (e.g., ODUE3) has a chance to be sent. To test 1. Set the system preference OverdueNoticeCalendar to « ignore calendar » 2. Set the following preferences: DefaultLongOverdueLostValue = Long Overdue DefaultLongOverdueDays = 15 3. Define days when the library is closed 3.1. Go to Tools > Calendar 3.2. Click on a Saturday (e.g., 2025-04-12) Fill Description = Saturdays, Click on "Holiday repeated every same day of the week." and Click on Copy to all libraries and submit 3.3. Repeat step 3.2. by clicking on Sundays (e.g., 2025-04-13) similarly. 4. Checkout an item to a patron of category type Board, and set due date to 2025-03-29 (15 days before today). 4.1. Click on "Show checkouts", click the barcode, and note the itemnumber. 5. Run: ./misc/cronjobs/longoverdue.pl --> The item should be flagged as overdue (e.g., item 378 appears in the output). 6. Now Enable the system preference OverdueNoticeCalendar. 7. Run longoverdue.pl again: --> The item is still detected as overdue, even though it should not be (due to holidays). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 33756] New: Wrong calculation of total amount spent?
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33756 Bug ID: 33756 Summary: Wrong calculation of total amount spent? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am trying to work out something in acquisitions and stumbled on this bit: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Bud… # Get all the budgets totals in as few queries as possible my $hr_budget_spent = $dbh->selectall_hashref(q| SELECT aqorders.budget_id, aqbudgets.budget_parent_id, SUM( | . C4::Acquisition::get_rounding_sql(qq|COALESCE(unitprice_tax_included, ecost_tax_included)|) . q| * quantity ) AS budget_spent FROM aqorders JOIN aqbudgets USING (budget_id) WHERE quantityreceived > 0 AND datecancellationprinted IS NULL GROUP BY budget_id, budget_parent_id |, 'budget_id'); If the amount is spent, I feel multiplying by quantity is incorrect. It should be quantityreceived. I am not sure yet where this is used and how it manifests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26757] New: SMS Test Button
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26757 Bug ID: 26757 Summary: SMS Test Button 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if there were a test button on the staff and opac interfaces for testing the SMS setting to make sure they work, rather than having to wait for a message to trigger, or having to setup a scenario to trigger a notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 17015] New: New Koha Calendar
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 Bug ID: 17015 Summary: New Koha Calendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehdi.hamidi(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org We are trying to create a new Koha calendar system. The one available right now is way too slow. This is the first patch of the calendar, it doesn't affect the functioning of the current calendar, but it works in parallel with it. Instead of having multiple tables for the holidays, we created one table, called discrete_calendar. This table contains the dates,branchcode, opening/closing hours, a note about the holiday and whether the library is open or not. The script misc/generate_discrete_calendar.pl fills the table discrete_calendar based on tables : repeatable_holidays, special_holidays, openinghours and branches. The script, by default, will add 2 years from the past and 1 year in the future in the table discrete_calendar. It also has an option to added more than 1 year in the future. The script misc/cronjobs/add_days_discrete_calendar.pl will add days in the future in the table discrete calendar. A day's opening and closing hours will be based on the same weekday from the week before. It will also check if the same day from last year was a holiday, if so, this will be counted as a holiday. The script makes sur there's at least 1 year in the future. So if it hasn't ran for 8 days, 8 days will be added in he future the next time the script is executed. There's also an atomic update to create the table. The current options are not final and they can be changed for convenience. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 528