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

[Bug 39204] New: Problem with cancelling a hold via SIP without marking it as waiting returns an error
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39204 Bug ID: 39204 Summary: Problem with cancelling a hold via SIP without marking it as waiting returns an error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Bug 38615: "When testing I noticed something both with and without the patch (so this is a general SIP question) If you place a hold and then try to cancel the hold with this command before checking the item into the hold shelf the SIP cancel request returns |AFError with transaction drop_hold:|" Easy to recreate with SIP emulator: 1. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 2. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode - 3. See the error: AFError with transaction drop_hold: -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 41402] New: Do not hide all items if there is a pref OpacMaxItemsToDisplay
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41402 Bug ID: 41402 Summary: Do not hide all items if there is a pref OpacMaxItemsToDisplay Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If there are too much items to process according to OpacMaxItemsToDisplay, ALL items are hidden. It is a bit weird to display every single of the n-1 items, but none of the n items once OpacMaxItemsToDisplay is reached. I propose to change the behaviour of this syspref to only display the first OpacMaxItemsToDisplay items and have a link to see more. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 28491] New: field 003 not updated after import
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28491 Bug ID: 28491 Summary: field 003 not updated after import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org I import some authority data from e.g. dnb.de, which contains: <controlfield tag="001">11915725X</controlfield> <controlfield tag="003">DE-101</controlfield> After the import, the local authority data looks like <controlfield tag="001">35</controlfield> <controlfield tag="003">DE-101</controlfield> So 001 now contains the internal Koha id (good), but 003 still points to DE-101 (i.e. dnb.de), which I think is bad, because if I look up the ID '35' in the linked DB DE-101, I will now get a bad result. I assume that 003 should be set to my MARCOrgCode Looking at the code, I find (in C4::AuthoritiesMarc, AddAuthority, 568ff) if (!$record->field('003')) { $record->insert_fields_ordered( MARC::Field->new('003', $marcorgcode), ); } So this behavior seems intentional? If so, I still find it very unlogical and buggy. I assume that both 001 and 003 should be overwritten with data pointing to the current Koha instance, and the original 001/003 "archived" in 035 and/or 040 I could easily provide a patch that changes this behavior, but I'm not sure if this would cause confusion / failing tests / etc. Maybe add an option to allow a force-overwrite of 003? Greeting, Thomas PS this seems slightly related to #25603 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 40701] New: Message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." doesn't display anymore
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40701 Bug ID: 40701 Summary: Message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." doesn't display anymore Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was trying to get the message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." to appear in main because I wanted to change it to "charge balance" or simply "balance" instead of "fine balance" (I got a comment from a confused client on 24.05 whose library doesn't charge fines...). It seems, this message doesn't appear anymore in main? It's still in the .inc though. To recreate: 1. Go to a patron account > Accounting > Create manual invoice 2. Add a Manual fee charge of 100 and click Save 3. Go to Details --> There is a message about the fee, but it doesn't say "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." 4. Go to Checkouts -- Same. I feel like it's an unintended change in behaviour brought by bug 28924, maybe? The IF right above the message was changed and I think that's what prevents the message from displaying, but I'm not sure enough to fix it myself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 37532] New: Protected status should have a permission to block editing patron
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37532 Bug ID: 37532 Summary: Protected status should have a permission to block editing patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, protected status prevents accidental deletion of a patron account. With bug 36085, an extra layer will be added to protect that status from being turned on or off with a permission. However, the account is not fully protected, as important information can be altered in the account by editing it. I would like to see an option for protected status, that would allow us to decide if this protected status will also prevent others from editing the account at all, unless they have the permission in bug 36085. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 40183] New: Record diff in action logs when editing notices
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40183 Bug ID: 40183 Summary: Record diff in action logs when editing notices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 Notices would be a good place to implement the diff column for action logs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38296] New: Investigate DataTables's extension StateRestore
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38296 Bug ID: 38296 Summary: Investigate DataTables's extension StateRestore Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33484, 36640 https://datatables.net/extensions/staterestore/index#Features Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33484 [Bug 33484] Ability to remember user's selected table configuration and search filters for tables https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31159] New: Can we drop the 'CircSideBar' preference and convert the sidebar to being collapsible?
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31159 Bug ID: 31159 Summary: Can we drop the 'CircSideBar' preference and convert the sidebar to being collapsible? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 I find it confusing that the CircSidebar is disabled by default. I propose we enable it and remove the preference replacing it with a collapsible navigation that gives us the best of both worlds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 41747] New: xt/js_tidy is failing on ill js files
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41747 Bug ID: 41747 Summary: xt/js_tidy is failing on ill js files Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org 20:04:28 koha-1 | # Failed test 'koha-tmpl/intranet-tmpl/prog/js/ill-availability.js should be kept tidy' 20:04:28 koha-1 | # at xt/js_tidy.t line 36. 20:04:28 koha-1 | 20:04:28 koha-1 | # Failed test 'koha-tmpl/opac-tmpl/bootstrap/js/ill-availability.js should be kept tidy' 20:04:28 koha-1 | # at xt/js_tidy.t line 36. 20:04:28 koha-1 | Everything up-to-date 20:04:28 koha-1 | # Looks like you failed 2 tests of 3. 20:04:28 koha-1 | [20:03:48] xt/js_tidy.t ................................................................ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 40366] New: Update the label export process to avoid Greybox modal
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40366 Bug ID: 40366 Summary: Update the label export process to avoid Greybox modal Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I propose that we update the label export process in order to avoid using a Greybox modal. We can just as easily move from page to page as the process progresses. -- You are receiving this mail because: You are watching all bug changes.

1 15