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

[Bug 42582] New: Uncaught TypeError when no z39.50 service is set
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42582 Bug ID: 42582 Summary: Uncaught TypeError when no z39.50 service is set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com to recreate: - start a ktd instance with a plugin that offers an ill_availability_services hook f.e. https://github.com/openfifth/koha-plugin-ill-avail-z3950 ktd --proxy --name main --single-plugin ~/git/koha-plugins/koha-plugin-ill-avail-z3950-master/ up -d ktd --name main --shell restart_all - login and configure plugin open http://main-intra.localhost/cgi-bin/koha/plugins/plugins-home.pl check one of the z39.50 targets and do not check 'Display results when making partner requests: ' <- this is where the bug is triggered enter partner id: 16 - edit a ILL patron and set an Primary email adress: http://main-intra.localhost/cgi-bin/koha/members/moremember.pl?borrowernumb… - enable ILLModule and ILLCheckAvailability http://main-intra.localhost/cgi-bin/koha/admin/preferences.pl?tab=interlibr… ILLModule: 'enable' ILLCheckAvailability: 'check' - create an ILL request: http://main-intra.localhost/cgi-bin/koha/ill/ill-requests.pl?method=create&… - on the following page open dev tools (F12 on Firefox) click 'Place request with partner libraries' - check error in console Uncaught TypeError: can't access property "enabled", services[0] is undefined The reason is a call for a property on a none existant services object in koha-tmpl/intranet-tmpl/prog/js/ill-availability-partner.js in function isEnabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42141] New: Design pattern introduced in 40191 does not work in staff SIP configuration
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42141 Bug ID: 42141 Summary: Design pattern introduced in 40191 does not work in staff SIP configuration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The introduced design pattern in 40191 which enhances every Vue resource with the possibility to 'Save and show resource', 'Save and list resources' or 'Save and continue editing' does not work staff clients SIP2 configuration To recreate go to Administration -> Self-service circulation (SIP2) and create one of the following: - institutions - accounts - system_preference_overrides Then try the 'Save', 'Save and continue editing' and 'Save and return to list' buttons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 42116] New: e.preventDefault is a function, needs parenthesis
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42116 Bug ID: 42116 Summary: e.preventDefault is a function, needs parenthesis Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I noticed that a few places in the codebase e.preventDefault is simply stated as an expression and not called, but preventDefault is a method and must be called to have any effect. > rg "\.preventDefault;" koha-tmpl/intranet-tmpl/prog/en/modules/clubs/clubs.tt 176: e.preventDefault; koha-tmpl/intranet-tmpl/prog/js/holds.js 750: e.preventDefault; koha-tmpl/intranet-tmpl/prog/js/cataloging_additem.js 79: e.preventDefault; 96: e.preventDefault; This might not be a trivial change because it could alter UI behavior. Bug 42012 fixes clubs.tt. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 38368] New: Background jobs: Batch item record deletion to list failed/succeeded items
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38368 Bug ID: 38368 Summary: Background jobs: Batch item record deletion to list failed/succeeded items 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: hanna.ikonen(a)sivistys.mikkeli.fi QA Contact: testopia(a)bugs.koha-community.org Currently background jobs do not list on visible record the items which have been handled. This causes issues especially when the background job fails, for example in batch item record deletion. Trying to solve which items have been worked with, you need to use several different reports. That means a lot of work hours, especially if, for example, the failed background job contains a lot of deleted items. My proposition is, that the background job -list would show which items were handled in the background whether it has failed or not. It would also be helpful if it showed information why it has failed/which item has caused the failure. It would standardize the information/notification system with the other batch processing jobs which list the things that have been worked on. To test: 1. Go to Administration and click Manage Jobs. 2. Select Status as "Failed" and Type "Batch item record deletion". 3. Open a failed background job. 4. Report only lists the job as failed, while "Detailed messages" is empty”. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17500] New: Use Elasticsearch to search for patrons
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17500 Bug ID: 17500 Summary: Use Elasticsearch to search for patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Adding and keeping up to date a new Elasticsearch index for patrons will allow us to use it to search for patrons. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 42529] New: Move GetAgeRestriction to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42529 Bug ID: 42529 Summary: Move GetAgeRestriction to Koha namespace Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org `C4::Circulation::GetAgeRestriction` parses age restriction strings (e.g. "FSK 16", "PEGI 6") from biblio metadata using the AgeRestrictionMarker system preference. It is used in 3 places (C4::Circulation twice, C4::Reserves once). I propose: * Add Koha::Biblio->age_restriction method that parses the restriction string and returns the numeric age (or undef if none) * Add Koha::Patron->meets_age_restriction($biblio) that returns whether the patron meets the age restriction * Replace all GetAgeRestriction callers with the new methods * Remove GetAgeRestriction from C4::Circulation * Move the existing test (t/Circulation/AgeRestrictionMarkers.t) to cover the new methods -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 42652] New: Add per-account option to allow restricted patrons to retain SIP inet access
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42652 Bug ID: 42652 Summary: Add per-account option to allow restricted patrons to retain SIP inet access Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org This patch adds a new per-account SIP2 configuration flag, `patron_restriction_blocks_inet`, that controls whether a patron with an account restriction (debarment) also has their SIP inet profile blocked. Currently, when a patron is restricted in Koha, the SIP inet field (FID_INET_PROFILE) is set to N. This means online services that use SIP for authentication â such as PC booking systems or printing services â also deny access to the restricted patron. Libraries that want to block a patron from borrowing items but still allow them to use digital services have no way to achieve this. With this flag set to 0/false on a SIP2 account, restricted patrons will receive Y for inet access, allowing them to authenticate to online services, while checkout privileges remain blocked as normal. The default (NULL or true) preserves existing behaviour: restrictions block both checkouts and inet access. Test plan: 1. Apply all patches and run the database update. 2. Go to Administration > SIP2 accounts and edit an account. 3. Confirm the new "Restrictions block internet access" toggle is visible. 4. Create a test patron and apply an account restriction to them. 5. With the toggle unset (default), authenticate the patron via SIP and confirm the patron status response shows charge privileges denied AND inet profile N. 6. Set the toggle to false/disabled for the account and re-authenticate. 7. Confirm the patron status response still shows charge privileges denied but inet profile is now Y. 8. Confirm a non-restricted patron is unaffected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42035] New: Add diff support to APIKEYS CREATE and DELETE action logs
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42035 Bug ID: 42035 Summary: Add diff support to APIKEYS CREATE and DELETE action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for the APIKEYS module (Koha/ApiKey.pm) already has diff support for MODIFY, REVOKE, and ACTIVATE actions. However, CREATE and DELETE actions do not pass the $original parameter. Affected calls in Koha/ApiKey.pm: - APIKEYS/CREATE (~line 84): logaction( 'APIKEYS', 'CREATE', $self->patron_id, $self, undef ); (passes $self as $infos but no $original; for CREATE, $self represents the new state) - APIKEYS/DELETE (~line 142): logaction( 'APIKEYS', 'DELETE', $patron_id ) (no info or original passed at all) For CREATE, passing $self as both $infos and $original (or with undef original) would allow the viewer to show what was created. For DELETE, the API key object should be fetched before deletion and passed as both $infos and $original so the log shows what was deleted. This is important for security audit trails. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42036] New: Add diff support to REPORTS action logs
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42036 Bug ID: 42036 Summary: Add diff support to REPORTS action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for saved reports does not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Currently log entries store the report name and SQL concatenated as a plain string. Affected calls: - reports/guided_reports.pl MODIFY (~line 250): logaction( "REPORTS", "MODIFY", $id, "$reportname | $sql" ) (no $original; only post-change state captured as a string) - reports/guided_reports.pl ADD (~line 594): logaction( "REPORTS", "ADD", $id, "$name | $sql" ) - C4/Reports/Guided.pm DELETE (~line 798): logaction( "REPORTS", "DELETE", $id, $data->report_name . " | " . $data->savedsql ) This bug covers updating these calls to pass structured hashrefs (e.g. { report_name => ..., savedsql => ... }) as $infos and, for MODIFY, the pre-change report data as $original, enabling proper before/after diff display in the action log viewer. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42037] New: Add diff support to ACQUISITIONS action logs
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42037 Bug ID: 42037 Summary: Add diff support to ACQUISITIONS action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for acquisitions events does not pass structured data or the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Currently the only logged acquisitions action is: - acqui/cancelorder.pl CANCEL_ORDER (~line 82): logaction( 'ACQUISITIONS', 'CANCEL_ORDER', $ordernumber ); (no $infos or $original passed) This bug covers a broader review of acquisitions logging to: 1. Update the CANCEL_ORDER log call to pass the order data (Koha::Acquisition::Order object or its unblessed hashref) as both $infos and $original so the log shows what was cancelled. 2. Identify and add logaction() calls for other significant acquisitions events (order creation, modification, receipt) that are currently unlogged or poorly logged, passing appropriate $infos and $original data to enable diff support. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2