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

[Bug 43508] New: Extract Koha::Account->add_lost_replacement_fee from chargelostitem
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43508 Bug ID: 43508 Summary: Extract Koha::Account->add_lost_replacement_fee from chargelostitem Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In a similar vein to bugs 43504, 43501, and 43500, this is preparation for 39756 that extracts logic which the new overdue triggers processing script will be relying on, and removes the userenv dependency. This time we extract Koha::Account->add_lost_replacement_fee from chargelostitem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43636] New: run_report.pl should be able to ignore report_sql_max_statement_time_seconds
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43636 Bug ID: 43636 Summary: run_report.pl should be able to ignore report_sql_max_statement_time_seconds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- Bug 39164 added a configuration option report_sql_max_statement_time_seconds run_report.pl is sometimes used for larger or more expensive reports so they can be run overnight when the server is less busy. It would be nice to have an option to disabled the statement time limit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39164] New: Add max_statement_time to SQL report quieries
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39164 Bug ID: 39164 Summary: Add max_statement_time to SQL report quieries Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: koha(a)trust-box.at Sometimes an unlucky report can create an issue for the DB server. To avoid that an easy to achieve fix would be to add a configurable timeout via max_statement_time to the query. This way the query would abort automatically if going over the time limit. See: https://mariadb.com/kb/en/aborting-statements/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 43561] New: Local use system preferences are shown in autocomplete but not found in searches
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43561 Bug ID: 43561 Summary: Local use system preferences are shown in autocomplete but not found in searches 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 41995 Target Milestone: --- To reproduce: - in admin, type "OPACdid" into the system preference search - see "OPACdidyoumean" is offered as a search term - click OPACdidyoumean, get an error that no such syspref exists - click into the Local Use system preferences, see OPACdidyoumean is there Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41995 [Bug 41995] Autocomplete for syspref search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43288] New: Change amount missing from printed fee receipts (change_given/change param mismatch)
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43288 Bug ID: 43288 Summary: Change amount missing from printed fee receipts (change_given/change param mismatch) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- members/pay.tt, members/paycollect.tt, and members/boraccount.tt all open members/printfeercpt.pl with a change_given= query parameter after taking a payment (for the FinePaymentAutoPopup auto-printed receipt, and for the manual Print action). However printfeercpt.pl only ever reads a 'change' param into its GetPreparedLetter substitute hash: substitute => { tendered => scalar $input->param('tendered'), change => scalar $input->param('change') } This matches the default ACCOUNT_CREDIT/CREDIT_PAYMENT notice templates, which use [% change | $Price %] (not change_given). Since nothing ever sends a change= param, the Change line on every printed fee receipt is silently blank. This isn't new: installer/data/mysql/db_revs/220600072.pl shows Koha previously migrated stored ACCOUNT_CREDIT letter content from [% change_given to [% change, so 'change' is the established name on the notice-template side. This patch fixes the three query strings that build the printfeercpt.pl URL to send change= instead of change_given=, rather than touching printfeercpt.pl or notice content. The change_given variable name is left alone everywhere else (hidden form fields, JS locals, Perl params) - this is purely about the query key at the printfeercpt.pl boundary. Test plan: 1. Set the FinePaymentAutoPopup system preference to "show" 2. Take a payment for a patron (via members/pay.pl or members/paycollect.pl) for less than the full amount tendered, so change is generated 3. Note the auto-popped-up receipt's Change line is blank 4. Apply the patch 5. Repeat step 2 6. Note the Change line now shows the correct amount 7. Repeat via the boraccount.pl account tab's Print action for a payment with change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41445] New: Wrong info about holds selection after hold suspending
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41445 Bug ID: 41445 Summary: Wrong info about holds selection after hold suspending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com After suspending a hold at patron's holds tab, incorrect information about holds selection is displayed. To reproduce: 1. Have unsuspended hold(s). 2. Go to patron's account, "Details" or "Check out", and "Holds" tab. 3. Click "Suspend" button in "Suspend?" column and confirm modal. 4. Notice: 4.1 checked header checkbox (first column) - not correct, checkbox(es) below are not checked 4.2 number of holds selected in line below the holds table - not correct, checkbox(es) above are not checked, buttons "Cancel selected" and "Suspend selected" are active -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81

[Bug 43633] New: RFC: task scheduling strategy - cron, background jobs, and plugin hooks
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43633 Bug ID: 43633 Summary: RFC: task scheduling strategy - cron, background jobs, and plugin hooks 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This is a discussion RFC, not a patch. No code changes are attached. Motivation Koha's approach to periodic/background work has grown organically across three different mechanisms, and it is not obvious which one new work should use: 1. misc/cronjobs/ - 56 standalone scripts wired into system cron (in packaged installs, via koha-common's shared /etc/cron.d, cron.daily, cron.hourly and cron.monthly files, which loop over every enabled instance with koha-foreach). 2. Koha::BackgroundJob - a message-queue-backed (STOMP/RabbitMQ) async task system, enqueued explicitly at user/API-action time and run by a persistent worker (misc/background_jobs_worker.pl). 3. The cronjob_nightly() plugin hook, invoked once per install by misc/cronjobs/plugins_nightly.pl, which fans out to every installed plugin's own nightly method (filterable by -m name=). There is also a community plugin, koha-plugin-crontab, which lets staff manage an instance's own crontab from the UI instead of editing it over SSH. That raised the underlying question this RFC wants to settle: should core lean into cron more (e.g. by encouraging/adopting per-instance user crontabs the way that plugin expects), or should more scheduling move into the background jobs framework, so that fewer new features need their own misc/cronjobs/*.pl script at all? Current state (verified against main) - koha-common's packaged cron model is multi-instance and root-owned: a handful of shared cron.d/daily/hourly/monthly files call koha-foreach across every enabled instance. It is not "one crontab per instance" today. - koha-plugin-crontab operates on a single instance's own user crontab (or a configured cron file) - a different ownership model from the above. Making core lean on that model would mean changing koha-common packaging itself (dropping the shared cron files, generating per-instance crontabs at koha-create time), and would not help non-packaged/dev installs at all. The plugin also has no plugin-to-plugin registration API; it is a UI over the existing crontab, not an execution backend other code can depend on. - Koha::BackgroundJob has no concept of recurring/time-based execution at all (no run_at, no cadence/cron expression). It is strictly an on-demand queue for work triggered by a user or API call. Adding scheduling to it would mean building a new subsystem (a cadence table plus a periodic dispatcher), and that dispatcher would still need something to trigger it - i.e. cron or a systemd timer underneath - while adding a hard dependency on the message broker and worker daemon staying up, which today's plain cron scripts do not need. - The cronjob_nightly() plugin hook already solves "how does a plugin get periodic execution" without adding its own crontab line or misc/cronjobs/ script: one core cron entry fans out to every installed plugin. Proposal for discussion - Do not migrate core's default packaged cron model to per-instance user crontabs. The koha-foreach/shared-cron-file model fits the common multi-instance production deployment; koha-plugin-crontab can remain an optional convenience layer for installs that want self-service scheduling, without core depending on it. - Do not move general-purpose recurring scheduling into Koha::BackgroundJob. It solves async execution of user-triggered work, not scheduling, and a scheduler bolted onto it would duplicate cron while adding a broker/worker dependency. - Do grow the cronjob_nightly()-style hook (for example additional cronjob_hourly()/cronjob_frequent() variants) as the sanctioned way for plugins to get periodic execution, instead of new misc/cronjobs/*.pl scripts or bespoke crontab entries per plugin. - Separately, for the subset of existing cron scripts that are already heavy/long-running (merge_authorities.pl, automatic_renewals.pl, and similar batch jobs), there may be value in having cron enqueue a Koha::BackgroundJob instead of running the logic inline, to get retry/status/permission-scoped visibility in the staff UI. That is an execution-model improvement for specific jobs, not a scheduling-model change, and it still needs cron (or a systemd timer) as the trigger. Open questions for the list 1. Is there appetite for formalising additional cronjob_<cadence>() plugin hooks (hourly, frequent/every-N-minutes) alongside the existing cronjob_nightly()? 2. Are there core cron scripts that the community would like to see converted to enqueue a Koha::BackgroundJob, to gain the existing background jobs UI/retry/permissions model? 3. Is per-instance user-crontab management (as koha-plugin-crontab provides) something core packaging should ever adopt, or should it stay a third-party/optional layer? Filed to start discussion on the koha-devel list / Bugzilla; no patch attached. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26288] New: Update the Select2 JS lib to version 4.1.0
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26288 Bug ID: 26288 Summary: Update the Select2 JS lib to version 4.1.0 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Bug 25727 updated Select2 to the latest stable release (4.0.13). We found some glitches about the width (see bug 25727 comment 19 for instance). It seems that the next 4.1 is going to fix it, but still beta. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 38310] New: DataTables - Use Select2 for column filters
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38310 Bug ID: 38310 Summary: DataTables - Use Select2 for column filters 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36640 We should apply Select2 to all of dropdown lists present in the column filters. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 43632] New: Koha Offline Circulation Tool (KOCT) settings can't list more that 20 branches
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43632 Bug ID: 43632 Summary: Koha Offline Circulation Tool (KOCT) settings can't list more that 20 branches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: johan.sahlberg(a)tidaholm.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- After configuring the KOCT settings and testing the connection you are supposed to choose the branch. The problem is that libraries that have more than 20 branches can not be listed in the drop down. This is because of a faulty API call to /api/v1/libraries which is supposed to return a list with all branches, but it only returns the first page which contains the fisrt 20 results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2