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

[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

[Bug 43626] New: Allow for specifying AutoILLBackendPriority per borrowing institution
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43626 Bug ID: 43626 Summary: Allow for specifying AutoILLBackendPriority per borrowing institution Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Currrently AutoILLBackendPriority is only per backend, but it would be nice if you could set it per institution. example: ISO borrowing plugin allows to set multiple lenders AutoILLBackendPriority will currently put all ISO lenders at the same level Libraries would like to be able to set priority per library, ideally with tiers (ie, lenders A,D,F together, then lenders C,B,E, and at the bottom lender g -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43620] New: Searching from acquisition basket does not work
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43620 Bug ID: 43620 Summary: Searching from acquisition basket does not work Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: minna.kivinen(a)hamk.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 206658 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206658&action=e… Screenshot of acquisition basket search 1. Open acquisitions 2. Search Vendor 3. Open Vedor acquisition basket Acquisitions in the basket show on a table. Above the basket there is a search -field. Search does not work right. If you type in letters it does not react at all. If you type in * character, it filters the list, but you can not clear the filter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42517] New: Allow option to set StrictHostKeyChecking=accept-new for SFTP
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Bug ID: 42517 Summary: Allow option to set StrictHostKeyChecking=accept-new for SFTP 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org SFTP keys have to be accepted on the command line level currently, it would be helpful if in the kohaconf we could set StrictHostKeyChecking=accept-new to streamline sftp setups, but still have it be controlled from the server side. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 35902] New: Add English country and language codes as authorised values to be using in cataloguing MARC21 008 builder plugin
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35902 Bug ID: 35902 Summary: Add English country and language codes as authorised values to be using in cataloguing MARC21 008 builder plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing a biblio record, you can launch a builder plugin for 008. Positions 15 to 17 hold a two- or three-character alphabetic code that indicates the place of publication, production, or execution. There is a link to a MARC Code List for Countries Positions 35 to 37 hold a three-character alphabetic code for language. There is a link to a MARC Code List for Languages. It would be helpful if these codes were available as authorised value categories, to prevent user typing error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43490] New: Advanced editor failing to load when 942$2 and 942$m missing values
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43490 Bug ID: 43490 Summary: Advanced editor failing to load when 942$2 and 942$m missing values Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- I don't know why but sometimes the advanced editor will fail to load and will throw this error: "Inserting collapsed marker partially overlapping an existing one" It seems to be when the 942$2 and 942$m are present in the MARC record but missing values. Somehow a default value of "ddc" gets generated for 942$2 and I can see 942$2 and 942$c widgets created but the Javascript seems to be doing some reiterative work and even though it's created the 942$c widget, it fails to detect it on a subsequent pass and the editor fails. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43320] New: Don't repeat a quoted search with more quotes when no results
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43320 Bug ID: 43320 Summary: Don't repeat a quoted search with more quotes when no results Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- On bug 31213 we added a fallback quoted search when no results were found. A side effect here is that a quoted phrase that has no results, will then repeat the search quoted, which has the effect of an unquoted search, and will return items that have the terms, but not the phrase. Before repeating the search, we should check if the search is already quoted, and not search again if so. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20