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

[Bug 40450] New: Add context for "To:" to allow for better translation
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40450 Bug ID: 40450 Summary: Add context for "To:" to allow for better translation Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com At least in German different translation is required for "To" in different context: * Sending an email "to" someone: "an" * Specifying a timeframe from - to: "bis" This problem is visible especially in this string, where notices.tt would require "An", but others would require "Bis": https://translate.koha-community.org/translate/koha/24-11/staff-prog/de/?ch… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23771] New: CAS/Shib Authentication can fail when multiple users with no userid/cardnumber defined and one of them is locked
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23771 Bug ID: 23771 Summary: CAS/Shib Authentication can fail when multiple users with no userid/cardnumber defined and one of them is locked Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When logging in via cas no userid is passed to checkpw, however, we still seek out users with a null userid/cardnumber. If one of those users has a locked account and it happens to be the one chosen, we won't continue to CAS/Shib login (or LDAP, but LDAP shouldn't get a blank userid) -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 13542] Subscription is the only table to store userid instead of borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13542 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40457 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40457 [Bug 40457] Wherever possible we should lookup using borrowernumber instead of userid/cardnumber -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40456] New: Make check_cookie_auth() use borrowernumber instead of userid/id
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40456 Bug ID: 40456 Summary: Make check_cookie_auth() use borrowernumber instead of userid/id Change sponsored?: --- Product: Koha Version: Main 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As noted on bug 40275, check_cookie_auth() could replace its userid/cardnumber lookups using Koha::Patrons->find_by_identifier but it seems like it would be better to actually have it use borrowernumber instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39535] New: Patron search in patron lists does not work for patrons without cardnumber
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39535 Bug ID: 39535 Summary: Patron search in patron lists does not work for patrons without cardnumber Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you "Add patrons" in a "Patron list", there is a "Patron search" box which does an API search. If the patron found does not have a cardnumber, a "null" value is used instead and adding the patron to the list silently fails. In 2025, many libraries don't use cardnumbers anymore. Cardnumber is also a nullable field in the database, so it does not make sense to use it in lieu of the real patron identifier (ie the borrowernumber). We should be using borrowernumber for this feature. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 34018] New: Patron image upload fails without cardnumber
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34018 Bug ID: 34018 Summary: Patron image upload fails without cardnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If a borrower doesn't have a cardnumber, you can't upload a patron image via the Patrons module. I realize this is because it leverages the /cgi-bin/koha/tools/picture-upload.pl tool which requires a file including cardnumbers or prompts for a cardnumber, but you should be able to use borrowernumber instead - at least via the Patron module. -- The way to do this would be to refactor tools/picture-upload.pl to use a Perl module, and then create a REST API endpoint for uploading the patron image. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 13542] Subscription is the only table to store userid instead of borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13542 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au, | |tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- Lastly... my one concern about letting plugins manage their own permissions is that I suspect that they just will allow anyone to do anything. I don't think I've ever reviewed a Koha Plugin that didn't have some kind of security vulnerability in it. Although usually it's SQL injection. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #9 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #8) > We're stuck in a tricky place. If we want to fix the security, we might have > to break some plugins. Or... We add a system preference. Something like "PluginsStrictPermissions", which requires run.pl to only work with methods "report", "tool", "admin", or "configure". Most plugins should be fitting in this paradigm. For plugins that aren't... they have to disable "PluginsStrictPermissions" and there they read a warning saying they need to either align their permissions with "report", "tool", "admin", or "configure" OR use this new "koha_authz" Koha plugin class method so that they handle permissions on their own. Maybe we start with "ExperimentalPluginsStrictPermissions" and default it to "off" or "warn" where "warn" would generates some warnings (maybe just in the logs) saying that the plugin is using an unconventional method for run.pl. And then in a release or two we change "ExperimentalPluginsStrictPermissions" to "PluginsStrictPermissions" and default it to "on" so people are forced to turn it off or update their plugins. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '25

21 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #8 from David Cook <dcook(a)prosentient.com.au> --- Ok, I have an idea germinating. We change ./plugins/run.pl so that flagsrequired => { catalogue => 1 }. This means that anyone with staff interface access can execute this staff interface Perl script. We wrap Koha::Plugins::Handler->run() with a "C4::Auth::haspermission()" check. We take care of our existing known use cases of "report", "tool", "admin", and "configure" which are pre-existing "plugins" subpermissions. If a method is not "report", "tool", "admin", or "configure", then we need to do something else. This is the use case mentioned by Martin here. And historically these users have required full plugins permissions to run the plugin. So some options coming to mind: 1. We interpret any other method as requiring a "report", "tool", or "admin" permission. In some ways it would make things more secure (ie these people wouldn't need full/configure permissions in order to run the plugins), but in other ways it would be less secure because now anyone could run weird plugin methods if they have any of the 'report', 'tool', or 'admin'. Not very optimal... 2. We add a new plugin class method called "koha_authz". If $class->can('koha_authz'), we try to delegate authorization to the plugin. If it doesn't have that class method, then we fallback to the status quo of requiring full "plugins" permissions? Yet, this is still a problem as I noted before. People with full plugins permission have access to too many plugin methods... -- We're stuck in a tricky place. If we want to fix the security, we might have to break some plugins. -- You are receiving this mail because: You are watching all bug changes.

1 0