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

[Bug 41696] New: Error handling in additem.pl is too specific and insufficient
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41696 Bug ID: 41696 Summary: Error handling in additem.pl is too specific and insufficient Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl additem.tt template "humanizes" every error it knows about, and ignores all others. This problem is noted in additem.pl itself (https://gitlab.com/koha-community/Koha/-/blob/166604f9f3938307de6ea5f2530b6…) The way it currently works is that any unhandled failure when adding/editing items fails quietly on the backend, but returns a 200 and shows a successful page to the user (a background job handling the same, but batched edit would fail visibly). The code and the template should be changed so that any caught exception leaves *some* trace in the interface and clearly indicates that an action has failed. (Patch incoming). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 41750] New: ForcePasswordResetWhenSetByStaff prohibits login via CAS
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41750 Bug ID: 41750 Summary: ForcePasswordResetWhenSetByStaff prohibits login via CAS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When ForcePasswordResetWhenSetByStaff is set to "enforce" and staff adds creates a new patron account, login by CAS is impossible. It took us a while to figure this out, since it just "won't work" without any helpful error message. I think there are different ways this could be handled. We could not check the password expiration date if a user authenticates through another external system (LDAP, CAS, OAuth2), since they cannot change the password then. The smallest solution might be warning on the pref, to not enable this for patron categories that use external authentication. I think in general it would be nicer to allow external authentication and still enforce if local login is used - there might be cases where both are the same patron category now and this would keep things more flexible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38769] New: Add plugins consent types to OPAC self registration process
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38769 Bug ID: 38769 Summary: Add plugins consent types to OPAC self registration process 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The new functionality allows plugins to add patron consent types to the system doesn't expose those consent types to the user at self registration time like we do for the data processing consent. We should have that option -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 31503] New: Groundwork for 20380 (mail consent)
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31503 Bug ID: 31503 Summary: Groundwork for 20380 (mail consent) 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 170

[Bug 31533] New: Add opt-in/opt-out flags to patron consents
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31533 Bug ID: 31533 Summary: Add opt-in/opt-out flags to patron consents Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Part of the 20380 set. Building on top of 31503. While we now only enforce the GDPR consent if the pref is set to Enforced, we leave other consents empty. Which actually is opt-in. They need to go to the consents page and enable the specific consent. If we would add opt-out, we can either add consents for all users or make PatronConsent a bit smarter and only register refusal (opt-out). It feels more consistent to add all consents to the table, and add them too in the self reg process. But when you add a new consent type and mark it as opt-out, we should then populate the table too. Do we also need a Mandatory flag? Historically, we treat the GDPR consent as such. Other consents may not be of that same category. But we might want the user to make an explicit choice there without the same exceptional approach that we use for GDPR. How do we get him on that page? If he arrives there, we can obviously allow saving only when those mandatories are filled.. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41662 --- Comment #15 from Andreas Jonsson <andreas.jonsson(a)kreablo.se> --- Sorry for not paying attention to this issue, but only look att the op parameter as this requires that this validation is made in checkauth: # FIXME This is only needed for scripts not using plack my $op = $query->param('op'); if ( defined $op && $op =~ m{^cud-} ) { die "Cannot use GET for this request" if $request_method eq 'GET'; } The comment suggest that this check may be removed at some point. Wouldn't it be safer to validate the method directly? - if ( $op && $op eq 'cud-save' ) { + if ( uc $query->request_method eq 'POST' ) { -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41748] New: ILLRequestsTabs: On loan-status won't sort under that tab
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41748 Bug ID: 41748 Summary: ILLRequestsTabs: On loan-status won't sort under that tab Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Created attachment 192285 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192285&action=e… ILLRequestsTabs Example of On loan-tab On loan -status won't sort under that tab in ILLRequestsTabs. If I make tab by Koha's example, the sorting won't work and under On loan-tab are detailss of all ILL-requests. There should be only details of ILL-requests that are on loan. Koha's example: - name: On loan status: - CHK -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 30968] New: opac-authorites-home.pl still accessible even when OpacAuthorities system preference is turned off
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30968 Bug ID: 30968 Summary: opac-authorites-home.pl still accessible even when OpacAuthorities system preference is turned off Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When the system preference OpacAuthorities is turned off, the page https://your.library.here/cgi-bin/koha/opac-authorities-home.pl is still accessible and likely shouldn't be. To test: set OpacAuthorities to Don't Allow try to visit https://your.library.here/cgi-bin/koha/opac-authorities-home.pl note that the page is still accessible. Thanks for checking it out! Liz -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41743] New: AWS Subsription Install Does Not Setup Correctly
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41743 Bug ID: 41743 Summary: AWS Subsription Install Does Not Setup Correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: Other OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: baceman007(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello, I subscribed to and used the CloudFormation install option on AWS to install Koha. I made sure my database is connected to my EC2 instance and that all relevant ports are open including 3306. When I try to enter a new record in the catalog, or import a record using the SRU option on the same page I receive the error. "Could not compile /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl: "prepare_host_field" is not exported by the C4::Biblio module Can't continue after import errors at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 29. BEGIN failed--compilation aborted at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 41. at /usr/local/share/perl/5.34.0/CGI/Compile.pm line 144" I tried commenting out the "prepare_host_field" parameter in addbiblio.pl but this setup does not allow me to do so as I do not have permission to modify the file via the AWS setup. Has anyone else run into this issue? How did you solve it? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41723] New: Library groups needs feature to limit switching libraries within the group
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41723 Bug ID: 41723 Summary: Library groups needs feature to limit switching libraries within the group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 We've wanted staff to be limited to switching libraries to specific libraries in their group. It makes sense to put a feature in library groups that could limit what libraries they can switch between, if allowed to switch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4