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

[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 41260] New: Running holds reminder cronjob with both triggered and holidays parameter may leave hold reminders unformed
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41260 Bug ID: 41260 Summary: Running holds reminder cronjob with both triggered and holidays parameter may leave hold reminders unformed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz If one runs cronjob holds_reminder.pl with both triggered and holidays parameter, reminders are not formed for holds which waiting date is same as library's closing date. This happens because triggered parameter changes crons functionality to handle only holds which waiting date is exactly the same one as variable $waiting_since. If date in holds waiting date is bypassed by above conditions reminder is never formed. To reproduce: 1. Find hold which waiting date is 2 days from day you're testing this or update one holds waitingdate value directly from database. 2. Set day which is same as the holds waiting date as closing day from that library's calendar where hold is waiting in. 3. Run perl holds_reminder.pl -v -days 2 --triggered -holidays -c => Note that no reminder is formed for the hold. 4. Wait for one day and run the cron again. => Note that no reminder is formed for the hold. 5. Now run cron without triggered parameter. => Reminder id formed. Triggered parameter is supposed to prevent spamming patrons with hold reminders, but it shouldn't prevent libraries from sending out reminders in cases where hold just happens to have waiting date on a closing date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41269] New: Patrons subpermissions should be fetched with borrowernumber instead of userid
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41269 Bug ID: 41269 Summary: Patrons subpermissions should be fetched with borrowernumber instead of userid Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In Koha-Suomi libraries we use cardnumbers as userids. This is done with a database trigger which sets cardnumber as userid when user is saved to database. Mostly this works well, but occasionally we have faced problems with patrons seemingly having no subpermissions. Patrons subpermissions are fetched from database with method get_user_subpermissions based on their userid. So even if they are saved in database they are not displayed in Koha's UI if userid is missing. While this isn't a major problem it can be confusing for staff members if they have accidentally created a patron without cardnumber/userid and then try to save permissions for them which seemingly are not saved. Also full permissions for patrons are still displayed normally so for consistency it would be logical to use borrowernumber to fetch subpermissions instead of userid. Method get_user_subpermissions is used in two places, member-flags.pl to fetch subpermissions and about.pl to check that SCO patron doesn't have extra permissions. As far as I can see changing it to use patrons borrowernumber shouldn't have any dramatic side effects. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34631] New: Independentbranches : Non-superuser should not be able to write Additional contents for other branches
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34631 Bug ID: 34631 Summary: Independentbranches : Non-superuser should not be able to write Additional contents for other branches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When syspref Independentbranches is enabled Non-superuser should not be able to write Additional contents for other branches To reproduce: 1- Connect to staff interface as superlibrarian 2- Enable IndependentBranches preference 3- Go to Tools -> HTML customizations 4- Crete an additional content for all libraries 5- Create or edit a borrower 5-1- Set permission for the borrower - catalogue - edit_additional_contents 4- Log in to the staff interface with the non-superlibrarian staff user 5- Go to Tools -> HTML customizations --> you can delete or edit the additional contents created by superlibrarian for All libraries 6- Click on New entry --> you can add additional content for other branches -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[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

[Bug 40899] New: When placing multiple holds at once the individual "Pickup location:" dropdowns to not update when changing the top level "Pickup at:" dropdown"
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40899 Bug ID: 40899 Summary: When placing multiple holds at once the individual "Pickup location:" dropdowns to not update when changing the top level "Pickup at:" dropdown" 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: 1. Place a hold on many items 2. Change the "Pickup at:" dropdown" to something else 2. Notice the "Pickup location:" dropdowns do not change with it This is a regression. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35