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

[Bug 42214] New: ERM usage database table erm_usage_yus contains incorrect data
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42214 Bug ID: 42214 Summary: ERM usage database table erm_usage_yus contains incorrect data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk There is an issue with the calculation of yearly usage: the yearly totals should equal the sum of all monthly usage values, but they currently do not. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 43176] New: ERM Usage Import Logs should not use a LIKE search on provider ID
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43176 Bug ID: 43176 Summary: ERM Usage Import Logs should not use a LIKE search on provider ID Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Target Milestone: --- The list of import logs seems to use a LIKE comparison rather than an exact match. As a result, import logs from provider ID 3 also returns Import logs associated with providers 37, 403, 131 and 318. This is the issue (contains): ... api/v1/erm/counter_logs?usage_data_provider_id=3&_page=1&_per_page=20&_match=contains&_order_by=-me.filename it should be (match=exact instead of contains): ... /api/v1/erm/counter_logs?usage_data_provider_id=3&_page=1&_per_page=20&_match=exact&_order_by=-me.filename Please also note similar Bug 43122. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 42217] New: ERM Usage – Harvesting Twice Does Not Overwrite Data
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42217 Bug ID: 42217 Summary: ERM Usage – Harvesting Twice Does Not Overwrite Data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk If reports are harvested more than once, the usage_count should be overwritten when the data has changed. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 43655] New: Authentication by identity provider does not create entry in action_logs
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43655 Bug ID: 43655 Summary: Authentication by identity provider does not create entry in action_logs Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: david_liddle(a)sil.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When using external authentication, specifically a Google OpenID Connect configuration or the same service set up as an OIDC Identity Provider, no entry is added to action_logs when a patron or staff member logs in through the service. For security, auditing, and troubleshooting purposes, the action logs should include such entries. Ideally, the log would identify which authentication method was used, distinguishing between local and external. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42088] New: ERM usage data provider summary not usable
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42088 Bug ID: 42088 Summary: ERM usage data provider summary not usable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk If you have harvested a lot of COUNTER usage data the usage data provider summery does not work any more. /cgi-bin/koha/erm/eusage/usage_data_providers/summary Error message : Something went wrong: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41305] New: Make the list of harvesting jobs more informative in erm/eusage/usage_data_providers
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41305 Bug ID: 41305 Summary: Make the list of harvesting jobs more informative in erm/eusage/usage_data_providers Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk I have not checked in main, but in 24.11 when you harvest a datasource this kind of message is displayed : "Job for report type DR has been queued. Check job progress." It could be more informative : adding the name of the source and the begin and end date could make it easier to identify a job if you want to get more information -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 38822] New: View easilty the months for which usage reports have been collected for a given source
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38822 Bug ID: 38822 Summary: View easilty the months for which usage reports have been collected for a given source Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com It could be nice to make it easy to view the months for which various usage reports have been collected for a given source (without the need to create a report in Koha) (FOLIO ERM or Coral could be source of inspiration) -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 42490] New: Allow configuration of LocalHoldsPriority to apply only at checkin, not when building holds queue
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42490 Bug ID: 42490 Summary: Allow configuration of LocalHoldsPriority to apply only at checkin, not when building holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Some libraries would like LocalHoldsPriority to impact only the choice of which hold should be filled when an on-loan item is returned, without impacting how the holds queue is built. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 43654] New: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930)
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 Bug ID: 43654 Summary: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930) 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 36930 fixed item search returning wrong results when 2+ added conditions were combined, by making the filter constructor in catalogue/itemsearch.pl detect whether parameters arrived as 'f[]' (bracket notation, sent by JS when there are 2+ conditions) or plain 'f' (single condition), and read/write consistently. However, the JSON-preprocessing block that merges DataTables column filters (free-text search box and dropdowns for library, item type, etc. in the results table) still unconditionally reads from multi_param('f') without brackets. With 2+ conditions, that call returns empty (JS sent 'f[]'), so the column filters get pushed onto an empty array and written back to the plain 'f' param — which the filter constructor further down (fixed by Bug 36930) never reads, since it's looking at 'f[]'. The column filters are silently ignored and the results table gets stuck on "Processing". Steps to reproduce: 1. Go to Cataloging > Item search. 2. Add 2 search conditions (e.g. Library = X AND Item type = Y). 3. Run the search, then try to filter further using one of the result table's column filters (e.g. type a value in a free-text column filter, or pick a value from a dropdown column filter). 4. The column filter has no effect / the table stays on "Processing". With only 1 condition, column filters work correctly. Fix: read/write the same 'f[]'/'q[]'/'op[]'/'c[]' vs 'f'/'q'/'op'/'c' convention in the preprocessing block, detected the same way the Bug 36930 filter constructor already does (checking for the bracketed param name among $cgi->multi_param). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42505] New: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Bug ID: 42505 Summary: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When returning an item required to fulfil a hold at another branch, with HoldsAutoFill set to 'Don't', the 'Hold found' modal (returns.tt: hold-found-modal / hold-found2 in older versions) is displayed and the librarian must choose 'Confirm hold and transfer' or 'Print slip, transfer, and confirm'. If the librarian clicks the print variant, the slip is opened via window.open() (Dopop()) called from $(document).ready on the page that loads *after* the form submission to confirm the hold. Because the window.open() call happens during a fresh page load, it is not associated with a user gesture, and modern browsers block it as an unsolicited popup. This affects the same code path used for HoldsAutoFill + HoldsAutoFillPrintSlip: the slip popup is fired on document.ready of the response page, with the same popup-blocker risk. Steps to reproduce ================== 1. Set HoldsAutoFill = Don't. 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. The 'Hold found' modal appears. 5. Click 'Print slip, transfer, and confirm'. Expected: the hold is confirmed and the hold transfer slip opens in a new window. Actual: the form submits and the hold is confirmed, but the slip popup is blocked by the browser. The librarian sees no slip and may not realise the slip was attempted. Root cause ========== In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print click handler sets a hidden input print_slip=1 and submits the form. The server (circ/returns.pl) sets the print_slip template parameter on the response, and the response page calls Dopop() (window.open) on document.ready. That window.open() is not within a user gesture event, so popup blockers reject it. Suggested fix ============= Open the print window synchronously inside the .print click handler, while the user gesture is still active. The reserve_id is already present in the modal form as a hidden input, and hold-transfer-slip.pl needs only the reserve_id; the slip content does not depend on the hold having been moved to Waiting state. The form submit to confirm the hold then proceeds in the main window as before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33