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

[Bug 38964] New: Fix column span in footer of staff interface account payment page
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38964 Bug ID: 38964 Summary: Fix column span in footer of staff interface account payment page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 33137 The footer of the table of charges on the account payment page has incorrect column spans, resulting in the rows having incorrect alignment. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33137 [Bug 33137] Make sure columns on transactions and 'pay fines' tab are matching up -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 38633] New: Calendar - Weekly closures are ignored when setting a yearly repeating holiday
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38633 Bug ID: 38633 Summary: Calendar - Weekly closures are ignored when setting a yearly repeating holiday Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)ukhsa.gov.uk QA Contact: testopia(a)bugs.koha-community.org There seems to be an issue in Koha when setting up a yearly repeating holiday in a range. Currently running Koha 23.11.10 I had not noticed this issue in previous versions - we would have been running 22.11 when I last set up a repeating closure range. We set in the calendar a yearly closure period from 20 December to 6 January each year. This year 21/22 December and also 28/29 December are weekends when the library is already closed. However if I look at the 2025 or 2026 calendars, those dates which are weekends in 2024 are showing as open if they are on a weekday in 2025 or 2026. They should be closed as they are still within the date range of the yearly repeating closure. On testing it appears that, if weekly repeatable holidays are set, Koha ignores those days in the holidays on a range (presumably because they are already marked as closed). You can see this clearly because they do not appear in the list of dates on the right. This does become an issue when you are using holidays on a range repeatable yearly. Our temporary workaround was to remove all of the repeating holidays. Then add in the Christmas/ New year closure range and the add back in the weekly Saturday and Sunday closures. It appears to be necessary to set the yearly repeatable holidays on a range first, and to add the weekly repeatable holidays afterwards. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 39712] New: Query parameters break the manual mappings in vue modules
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39712 Bug ID: 39712 Summary: Query parameters break the manual mappings in vue modules Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, philip.orr(a)lmscloud.de If a url in a vue module contains query parameters the mapping for the manual fails and redirects to the homepage when 'Help' is clicked To reproduce navigate to the agreements page in ERM and create at least one. On the list page, use the filters so that you have query parameters in the page URL. Click the 'Help' button - you just get the manual home page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 22415] New: Koha::EDI should not use Log::Log4perl directly
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22415 Bug ID: 22415 Summary: Koha::EDI should not use Log::Log4perl directly Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We have Koha::Logger for instantiating Log4perl loggers now.. it should be used here too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 38423] New: EDIFACT invoice files should skip orders that cannot be receipted rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38423 Bug ID: 38423 Summary: EDIFACT invoice files should skip orders that cannot be receipted rather than failing to complete Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT invoice file, if the process finds a problematic order (usually a cancelled order or a deleted bibliographic or item record) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the orders in the file have to be manually receipted by library staff as vendors are reluctant to re-process part invoices. It would be preferable if the process could skip, and report any problem orders but complete all other receipts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 40205] New: "Default checkout, hold and return policy" cannot be unset
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40205 Bug ID: 40205 Summary: "Default checkout, hold and return policy" cannot be unset Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Rules in the "Default checkout, hold and return policy" section of the circulation rules can no longer be deleted/unset. To test: - Go to administration > circulation rules - Enter a value in one of the fields of the "Default checkout, hold and return policy" section - Save - Verify the value you entered was stored and is shown on the page - Click on the button "unset" - Confirm the confirmation question - Verify the value still shows, the rule was left unchanged The expected behavior is that the rule would be deleted and in the first column of the table it should say "Not set" as for a new installation. This was confirmed to be working correctly in 22.11. Broken in 24.11 Working correctly in main. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 40771] New: Wrong transfer breaking check in for holds when using library transfer limits
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40771 Bug ID: 40771 Summary: Wrong transfer breaking check in for holds when using library transfer limits 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(a)bywatersolutions.com Bug 39750 fixed the case of a transfer with no hold - it seems the same problem can occur when the transfer is for a hold: Line 178 of returns.pl my $hold = Koha::Holds->find($reserve_id); if ($diffBranchSend) { my $tobranch = $hold->pickup_library(); # Add transfer, enqueue if one is already in the queue, and immediately set to in transit my $transfer = $item->request_transfer( { to => $tobranch, reason => 'Reserve', enqueue => 1 } ); $transfer->transit; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 41008] New: bulkmarcimport.pl -d broken for authorities
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41008 Bug ID: 41008 Summary: bulkmarcimport.pl -d broken for authorities Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz In 24.11 the system complains about a FK constraint to the new oai tables when the script is run with -a -d. DBI Exception: DBD::mysql::db do failed: Cannot truncate a table referenced in a foreign key constraint (`koha_xxx`.`import_oai_authorities`, CONSTRAINT `FK_import_oai_authorities_1` FOREIGN KEY (`authid`) REFERENCES `koha_dlre1`.`auth_header` (`authid`)) at /usr/share/perl5/DBIx/Class/Schema.pm line -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 40903] New: OPAC advanced search applies a location limit of the logged-in library by default
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40903 Bug ID: 40903 Summary: OPAC advanced search applies a location limit of the logged-in library by default Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This is caused by Bug 36742. It exists in main but starts in 24.11. The OPAC advanced search now automatically applies a limit to the 'Location and availability' section using the patron's logged in library, even if there are multiple libraries in the system. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 40622] New: Bug 38233 not properly applied to 24.11.x+
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40622 Bug ID: 40622 Summary: Bug 38233 not properly applied to 24.11.x+ Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org A close examination of the code in "C4/ILSDI/Services.pm" shows that only half the patch from bug 38233 was applied to 24.11.00. It was properly backported to 24.05.06, so anyone upgrading from 24.05.06 to 24.11.00 would experience a regression. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41