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

[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