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

[Bug 27173] New: Add plugin hooks for authority record changes
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27173 Bug ID: 27173 Summary: Add plugin hooks for authority record changes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Authority counterpart for bug 22709 on biblio and item records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 35445] New: OPAC registration verification triggered by email URL scanners
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35445 Bug ID: 35445 Summary: OPAC registration verification triggered by email URL scanners Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 I've noticed that Microsoft Safe Links is triggering /cgi-bin/koha/opac-registration-verify.pl?token=X links. This means that the end user ends up seeing "Registration invalid" because the Microsoft link scanner has already verified the registration by hitting the page with a GET. We should update opac-registration-verify.pl so that it requires the user to click a button for a POST form confirming their registration. (NOTE: Since opac-registration-verify.pl performs a state change, it should be a POST anyway.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 36161] New: ISLDI AuthenticatePatron broken when LDAP enabled and auth falls back to internal connection
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36161 Bug ID: 36161 Summary: ISLDI AuthenticatePatron broken when LDAP enabled and auth falls back to internal connection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org bug 34893 passes a patron object back from authentication, however, when LDAP is enabled we define the patron from the return of checkpw_ldap When the ldap auth is a failure, we fallback to internal, however, we don't redefine the patron object In the code: 1965 if ( defined $userid ) { 1966 $patron = Koha::Patrons->find( { userid => $userid } ); 1967 $patron = Koha::Patrons->find( { cardnumber => $userid } ) unless $patron; 1968 } . . . 1980 } elsif ( $ldap && defined($password) ) { 1981 my ( $retval, $retcard, $retuserid ); 1982 ( $retval, $retcard, $retuserid, $patron ) = checkpw_ldap(@_); # EXTERNAL AUTH . . . 2026 # INTERNAL AUTH 2027 if ($check_internal_as_fallback) { 2028 @return = checkpw_internal( $userid, $password, $no_set_userenv ); 2029 push( @return, $patron ); 2030 $passwd_ok = 1 if $return[0] > 0; # 1 or 2 2031 } line 1982 undefs, line 2029 returns it In ilsdi: 397 my ($status, $cardnumber, $userid, $patron) = C4::Auth::checkpw( $username, $password ); 398 if ( $status == 1 ) { 399 # Track the login 400 $patron->update_lastseen('connection'); 401 return { id => $patron->borrowernumber }; 402 } We die on undefined patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25370] New: Create whitelist of plugins allowed to be installed
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25370 Bug ID: 25370 Summary: Create whitelist of plugins allowed to be installed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org This feature would provide a whitelist of plugins that are allowed to be installed in Koha. This whitelist would be managed by some kind of administrator*. This feature coupled with Bug 24632 would allow Koha users to only installed certain authentic plugins from trusted providers. (*I've been thinking that a superlibrarian really should be able to configure all aspects of Koha. However, from a vendor perspective, there are quality of service and security risks that comes with that. So perhaps the administrator level should be configurable. Defaulting to superlibrarian but optionally being switched to backend sysadmin for vendors, so that they can have ultimate say, when running on their own hardware.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 34235] New: Make virtualshelves preference more granular
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34235 Bug ID: 34235 Summary: Make virtualshelves preference more granular Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently the "virtualsheves" preference gives this choice : "Allow staff and patrons to create and view saved lists of books: " 1: "Yes" 0: "No" It should be more granular, and allow the creation of lists by - staff only - patrons only - staff and patron - nobody Also it should be renamed, as the feature in Koha UI is not called "virtual shelves" but "lists". And a list can contain any material, not only "books". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 36910] New: virtualshelves - Split into two system preferences
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36910 Bug ID: 36910 Summary: virtualshelves - Split into two system preferences Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Requesting that the system preference virtualshelves be split into two preferences- one for public and one for staff. We do not want the public to be able to create lists in our OPAC; however, turning off this preference disables the "Add To List" function in Koha, which our staff use everyday. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27503] New: Rename system preference virtualshelves to AllowLists
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27503 Bug ID: 27503 Summary: Rename system preference virtualshelves to AllowLists Change sponsored?: --- Product: Koha Version: unspecified 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org find all of the places in the code that refer to the 'virtualshelves' system preference and rename them to 'AllowLists' write an atomic update to rename the virtualshelves system preference to AllowLists in the preferences table in the database rename the virtualshelves syspref in sysprefs.sql refer to bug 10328 for an example -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 32957] New: Add option to CMS pages to make page private
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32957 Bug ID: 32957 Summary: Add option to CMS pages to make page private 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently CMS pages (Bug 15326) will be public or private, depending on the OpacPublic system preference. It would be cool to set specific pages as private so a login is forced. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 37421] New: Apply Protected Status to a Patron Category
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37421 Bug ID: 37421 Summary: Apply Protected Status to a Patron Category 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if the option of the protected status for patrons to be optional by patron category. So when a library creates a new patron within this patron category, then the protected status is automatically applied. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 38206] New: Batch item modification display multiple identical links to return to batch item modification page
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38206 Bug ID: 38206 Summary: Batch item modification display multiple identical links to return to batch item modification page Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 172976 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172976&action=e… Screenshot batch item modification multiple links After doing a batch item modification, the confirmation page shows multiple links to start a new batch item modification (see the screenshot attached): 1- A blue box saying that the job has been enqueued. This box contains a first link to the batch item modification page. 2- Under the blue box, a first link "Return to batch item modification" 3- Under the previous link, a second link "Return to batch item modification" with some additional skin. All these links are working and going to the same page, but links 2 and 3 are at the same place and only one should be displayed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2