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

[Bug 39224] New: Move Shibboleth config from koha-conf to the DB
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39224 Bug ID: 39224 Summary: Move Shibboleth config from koha-conf to the DB Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: jacob.omara(a)ptfs-europe.com Reporter: jacob.omara(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 38201 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 [Bug 38201] VueJS architecture rethink -- You are receiving this mail because: You are watching all bug changes.

1 201

[Bug 41367] New: Staff user interface - no sidebar menu when on record sources pages
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41367 Bug ID: 41367 Summary: Staff user interface - no sidebar menu when on record sources pages Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are no sidebar menu items when you are on record sources pages: 1. Go to Administration > Catalog > Record sources. 2. Note that there are no standard sidebar menu items on the left-hand side. 3. Add a new record source. 4. Note the same as step 2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 41343] New: Overdue report is too intensive on systems with many overdues
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41343 Bug ID: 41343 Summary: Overdue report is too intensive on systems with many overdues Initiative type: --- Sponsorship --- status: 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 41432] New: Add prefetch to improve performance of holds page
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41432 Bug ID: 41432 Summary: Add prefetch to improve performance of holds page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com To view the issue: 1 - Add a bunch of holds to a record https://github.com/kidclamp/handy-koha-script/blob/main/randhold.pl 2 - Enable profiling: https://wiki.koha-community.org/wiki/Profiling_with_Devel::NYTProf#NYTProf_… 3 - Browse to the record and load the holds table 4 - View the flame graph for the request like instructions in #2 5 - Note that Koha::Hold->borrower and Koha::Hold->item take a lot of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 40777] New: 500 Error: Something went wrong when loading the table Should Exit Cleanly
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40777 Bug ID: 40777 Summary: 500 Error: Something went wrong when loading the table Should Exit Cleanly Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It's possible this is related to/a duplicate of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40762 but I am not certain. In Koha 24.05 and 24.11, in the staff interface, if a bib with an item without a 952$a and 952$b is imported, when the staff member then goes to the bib record they receive a modal pop-up stating "Something went wrong when loading the table. 500: error". If they click OK on that message, a processing box sits on the screen (you can see the bib loaded behind it) and spins. The console log shows: datatables_24.1107000.js: 408 DataTables warning: table id=holdings_table - Ajax error. For more information about this error, please see https://datatables.net/tn/7 The "processing" box is not modal and it is possible to click on Edit, Manage items, and then edit the problem item to add the missing Home and Current libraries and resolve the cause of the error. This behavior does not occur in 23.11. While, of course, the item needs the Home and Current library, the error alert is a change in expected behavior from staff member perspective. A cleaner exit with a more informative message than a 500 error seems preferable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 43231] New: Bug 40658 breaks CLI for 25.11
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Bug ID: 43231 Summary: Bug 40658 breaks CLI for 25.11 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: rel_25_11_candidate Severity: blocker Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aleisha(a)catalyst.net.nz, dghdghfghfgh04(a)gmail.com, lucas(a)bywatersolutions.com, mark(a)hofstetter.at, martin.renvoize(a)openfifth.co.uk, nick(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 40658, 42795 Target Milestone: --- +++ This bug was initially created as a clone of Bug #42795 +++ This happened when trying to upgrade one of our Koha instances from Koha 25.11.04 to 25.11.05: Upgrade to 25.11.04.011 [18:49:23]: Bug 40658 - Ensure local-number is sortable ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_cust_biblios". Reason was: "mapper [local-number] cannot be changed from type [integer] to [text]". Index needs to be recreated and reindexed' So.. somehow the type is wrong in the index itself which makes me think we need to better catch that case and trigger a full re-index in a background task or something instead when that happens. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40658 [Bug 40658] When sorting by local-number we should use the sort field https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42795 [Bug 42795] Bug 40658 breaks CLI for 25.11 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 40383] New: Modernise the EDIFACT Message display modal
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40383 Bug ID: 40383 Summary: Modernise the EDIFACT Message display modal Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 40334 In bugs 40333 and 40334 we split out the modal display of raw edifact messages and allowed them to be display directly on the related basket and invoice pages. This patch aims to modernise their display to allow for both the 'raw' mode as well as a mode modern and easily navigable 'tree' view mode. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40334 [Bug 40334] When EDIFACT is enabled, one should be able view the corresponding EDIFACT QUOTE and ORDER messages on the Koha Basket page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 110

[Bug 40040] New: RTL CSS files not loaded in templates; legacy right-to-left.css causing UI issues
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40040 Bug ID: 40040 Summary: RTL CSS files not loaded in templates; legacy right-to-left.css causing UI issues Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: karamqubsi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 182880 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182880&action=e… RTL: Dropdown menus to have background colors that make text unreadable Hello everyone, Currently, the staff interface loads both regular CSS files for LTR and then adds `right-to-left.css` on top when in RTL (bidi) mode. This approach is inefficient and can lead to styling conflicts. The OPAC interface already correctly loads RTL-specific CSS files directly when in RTL mode. The right-to-left.css file is manually maintained and not generated by Gulp, unlike other RTL files that are automatically generated from their LTR counterparts. This results in inconsistent RTL styling. Currently, right-to-left.css is causing dropdown menus to have background colors that make text unreadable (see attachment). I preparing a patch to fix that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 43330] New: C4::Tags fails to compile when TagsExternalDictionary is configured
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43330 Bug ID: 43330 Summary: C4::Tags fails to compile when TagsExternalDictionary is configured Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When the TagsExternalDictionary system preference contains a value, C4::Tags fails to compile with: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. This can cause HTTP 500 errors throughout the staff interface on pages which load C4::Tags, including the staff home page, catalog detail pages, and Tools. Observed on Koha 25.11.06. The problem appears to be caused by the order in which check_install is imported in C4/Tags.pm. Currently C4/Tags.pm contains: use Modern::Perl; use base 'Exporter'; use C4::Context; BEGIN { ... my $ext_dict = C4::Context->preference('TagsExternalDictionary'); if ( $ext_dict && !check_install( module => 'Lingua::Ispell' ) ) { warn "Ignoring TagsExternalDictionary, because Lingua::Ispell is not installed."; $ext_dict = q{}; } ... } but Module::Load::Conditional is loaded later: use Module::Load::Conditional qw( check_install ); Because the check occurs inside a BEGIN block, the BEGIN block is executed during compilation before Perl reaches the later `use Module::Load::Conditional` statement. As a result, when TagsExternalDictionary has a non-empty value, Perl attempts to call check_install() before that function has been imported. When TagsExternalDictionary is empty, the problem is hidden because this expression short-circuits: $ext_dict && !check_install(...) so check_install() is never called. To recreate: 1. Set the TagsExternalDictionary system preference to a non-empty value, for example: /usr/bin/ispell 2. Restart Plack if necessary. 3. Visit a staff interface page which loads C4::Tags, such as the staff home page or a bibliographic detail page. OR reproduce directly from the command line: perl -MC4::Tags -e 'print "C4::Tags loaded OK\n"' 4. Observe: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. BEGIN failed--compilation aborted at C4/Tags.pm line 53. Compilation failed in require. BEGIN failed--compilation aborted. 5. Clear TagsExternalDictionary and clear/update the system preference cache. 6. Run the same command again. 7. C4::Tags loads successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 41358] New: action logs info column should always store JSON
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41358 Bug ID: 41358 Summary: action logs info column should always store JSON Initiative type: --- Sponsorship --- status: 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 In C4/Circulation.pm: # Log the checkout if ( C4::Context->preference('IssueLog') ) { my $info = $item_object->itemnumber; if ( defined($confirmations) || defined($forced) ) { $info = to_json( { issue => $issue->issue_id, branchcode => $issue->branchcode, itemnumber => $item_object->itemnumber, confirmations => $confirmations, forced => $forced }, { pretty => 1, canonical => 1 } ); } logaction( "CIRCULATION", "ISSUE", $patron->borrowernumber, $info, ); } It appears there is a way, if $forced and $confirmations is undef, to store just the itemnumber. If we are going to store JSON it should always be JSON. Storing the itemnumber sometimes and a JSON object other times makes reporting really hard. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55