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

[Bug 33627] New: OAI-PMH script build_oai_sets.pl is slow and memory angry
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '26

15 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33627 Bug ID: 33627 Summary: OAI-PMH script build_oai_sets.pl is slow and memory angry Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 15108 optimize set search but there's the same issue in: ./misc/migration_tools/build_oai_sets.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 17498] New: Expose system preference values to JavaScript in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17498 Bug ID: 17498 Summary: Expose system preference values to JavaScript in the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org We process a lot of JavaScript in the OPAC templates, usually because there are template variable which need to be processed. Some of these variable, like system preferences, are a global setting which is common to many pages in the OPAC. I propose that these settings be defined in embedded JavaScript so that the scripts themselves can be moved to a separate file. In my proposal, opac-bottom.inc will contain a section like this: <script type="text/javascript"> if (typeof KOHA == "undefined" || !KOHA) { var KOHA = {}; } KOHA.paths = { "interface_theme":"[% interface %]/[% theme %]" } KOHA.preferences = { "BakerTaylorEnabled" : [% IF ( Koha.Preference( 'BakerTaylorEnabled' ) == 1 ) %]1[% ELSE %]0[% END %], ...and then an separate JS file will use those variables to conditionally load resources: if( KOHA.preferences.Coce && KOHA.preferences.CoceProviders ){ KOHA.externalResources.push( KOHA.paths.interface_theme + "/js/coce.js" ); var NO_COCE_JACKET = _("No cover image available"); } if( KOHA.externalResources.length > 0 ){ Modernizr.load({ load: KOHA.externalResources }); } I'd appreciate comments anyone might have on this system. My goal, if this works well, is to then add a JavaScript concatenation/minification task for OPAC js assets. Moving as much JS as possible out of the templates will help us take advantage of that minification. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 36188] New: Allow to sort lists by items.dateaccessioned of item records
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36188 Bug ID: 36188 Summary: Allow to sort lists by items.dateaccessioned of item records 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently you can sort a list by 'Date added', but this is the date the record was added to the list. It would be nice if libraries could sort lists by the items.dateaccessioned of linked items. A use case for this would be a 'New resources' list - where the library curates a list of records including bib records who have linked items recently purchased. The library would want the list to be sorted by items.dateaccessioned descending i.e. newest first. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[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 18623] New: Send notification on creation of manual invoice
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18623 Bug ID: 18623 Summary: Send notification on creation of manual invoice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if when adding a manual invoice (say for a damaged item) an e-mail notification could be sent. Currently to tell the patron without them logging into the OPAC or coming into the library we have to send the e-mail manually. This is time consuming if we have a lot of damaged items being processed at once. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[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 32488] New: add indexes for content, media and carrier type
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '26

14 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32488 Bug ID: 32488 Summary: add indexes for content, media and carrier type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I don't think there are indexes for those MARC21 fields 336 - Content Type (R) 337 - Media Type (R) 338 - Carrier Type (R) nor for their UNIMARC equivalent 181 - Content form 182 - Media type 183 - type of carrier It could be nice to add those indexes and to add the ability to use them in advanced search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[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 31487] New: Add emails to message queue by longoverdue script options
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '26

13 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31487 Bug ID: 31487 Summary: Add emails to message queue by longoverdue script options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some customers request the possibility of sending an additional reminder when processing longoverdues. I think this may be useful for some and given that it remains an option, it does not handicap those who do not want to use it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23