https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |new feature -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #3 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 103461 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103461&action=edit Bug 25245: Add plugins_nightly.pl to the default cron -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #4 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Test plan 1/ Apply patch 2/ Ensure your cron setup calls the new plugins_nightly.pl 3/ Install the recalls plugin and skip the 'setup cron_nightly.pl' step 4/ The recalls plugin should function correctly even though you've not done the manual cron intervention. 5/ Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103460|0 |1 is obsolete| | Attachment #103461|0 |1 is obsolete| | --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 103497 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103497&action=edit Bug 25245: Add plugins_nightly.pl cronjob script This script simply iterates through installed plugins that impliment a cronjob_nightly method and runs said method. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl Status|Signed Off |Failed QA --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Some QA comments: use Modern::Perl Where do you need FindBin for here? I understand the test on enable_plugins but I feel that it should be part of GetPlugins somehow. If you did not enable them, GetPlugins should take care of it and return nothing. The if(@plugins) is not needed. You are looping thru @plugins inside. Why do you warn $_ ? Second patch If you are adjusting the debian koha-conf, you should also touch the other one. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103497|0 |1 is obsolete| | --- Comment #8 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 103767 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103767&action=edit Bug 25245: Add plugins_nightly.pl cronjob script This script simply iterates through installed plugins that impliment a cronjob_nightly method and runs said method. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103498|0 |1 is obsolete| | --- Comment #10 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 103769 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103769&action=edit Bug 25245: Add plugins_nightly.pl to the default cron -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103768|0 |1 is obsolete| | --- Comment #12 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 103775 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103775&action=edit Bug 25245: (follow-up) Use Koha::Logger Update script to use Koha::Logger to capture method failures. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103776|0 |1 is obsolete| | --- Comment #14 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 103778 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=103778&action=edit Bug 25245: Add plugins_nightly.pl to the default cron -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #16 from David Cook <dcook@prosentient.com.au> --- Oh... I like the sound of this. Could be very handy. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #18 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Marcel de Rooy from comment #17)

(In reply to Martin Renvoize from comment #15)

...

...

Why do you warn $_ ?

Following prior art. It makes sense to warn like this for such errors. I have however added a Koha::Logger based log line too now so we don't lose warnings for cases where cron sends them to dev/null.

You probably mean something else? Like $@ ? The wonderous names of Perl special variables. I am really not sure what $_ would be referring to in this catch block?

eval sets $@, Try::Tiny preserves it just in case you need it for other purposes, and sets $_. So, yes: it is the correct way with Try::Tiny. Look at all the API controllers for examples. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #20 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Ah.. sorry.. I hadn't spotted you were worried about the$_ as apposed to $@.. I thought it was the introduction of a 'warn' at all you were commenting on. Yes, as Tomas explains, Try::Tiny catches $@ and throws it into $_.. it's a peculiarity of that module.. I've wondered for a while about switching it out with Syntax::Keyword::Try which I believe is now recommended by the Perl echelons. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #22 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #21)

I have the feeling that this should have been implemented on top of bug 22417 (with bug 1993 in mind).

Is there any reason this cannot be updated to use the functionality of those bugs once they've been taken care of? It doesn't look like there is a definite end in site for them. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #24 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- The main inconvenient of this implementation is that the time the job will start is not configurable. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #26 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #23)

(In reply to Kyle M Hall from comment #22)

...

(In reply to Jonathan Druart from comment #21)

...

I have the feeling that this should have been implemented on top of bug 22417 (with bug 1993 in mind).

Is there any reason this cannot be updated to use the functionality of those bugs once they've been taken care of? It doesn't look like there is a definite end in site for them.

I agree here. Bug 22417 is a longer shot IMHO.

I agree with everyone in a way. I've spent years talking about and working on task scheduler functionality for Koha, and I don't think it's happening any time soon. Cron is a well-established familiar task scheduler that can do a good enough job. I'd argue Bug 22417 tries to be too comprehensive, and that we'd be better off just adding RabbitMQ and Net::Stomp as dependencies, and then doing a light experimental implementation here. However, even if we had only 1 worker consuming from RabbitMQ, that's another process to manage. It adds new administrative overhead and fragility that we don't have by continuing to use cron. Frido also made a good point back in Portland about queue based task schedulers (like the one I wrote). From a vendor point of view, you might not want all your Koha instances running their background jobs at the same time. If those background jobs use APIs, you might end up hitting rate limits for instance. Or if you're sending out lots of emails, you might get flagged as a spammer. So it becomes prudent for vendors to be able to stagger background jobs on a server. Of course, that criticism applies to using cron.daily for background jobs too. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #28 from David Cook <dcook@prosentient.com.au> --- Actually, in Jonathan's defence again, on Ubuntu 18.04 it wouldn't be a "nightly" method so much as a daily/every morning method when run in cron.daily, as it's set up to run at 6:25am out of the box. Maybe it should go in /etc/cron.d/koha-common instead with a better time defined. And then local admins can customize that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #104345|0 |1 is obsolete| | --- Comment #31 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Comment on attachment 104345 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104345 Bug 25188: Make circulation notes more prominent on the patron details tab Wrong bug number... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #33 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #32)

You can happily gain a little more control over the scheduling within your plugin code by doing a date comparison as the first part of the job in your plugin so one could for instance set the tasks to take place ever X days rather than nightly, or every Friday for example.

What do you think about putting the cronjob in /etc/cron.d/koha-common instead of /etc/cron.daily/koha-common? The former could run at very configurable time whereas the latter runs at 6:25am out of the box. I could see Koha sysadmins customizing /etc/cron.d/koha-common much more readily than /etc/crontab (as you couldn't want to changethe time for all daily cronjobs). I think that would be a very reasonable change to make to the current patch set? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #35 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I agree with Katrin here I think.. I would say it's clearer to have the default in the .daily file as it's intended to be run daily and for an admin to move it to .d if they are keen to specify an exact time. Also, as an aside, it is my understanding that these two schemes work in different ways.. cron.d runs more like the original cron and just 'does a thing at time X' where as cron.daily (and friends) uses anacron in the background and as such 'does thing some time after X, with random delay Y and retries if the server is down'. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #37 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #35)

I agree with Katrin here I think.. I would say it's clearer to have the default in the .daily file as it's intended to be run daily and for an admin to move it to .d if they are keen to specify an exact time.

I suppose so. I'm just thinking about out-of-the-box minimal installations. It's no drama for me to change a cronjob time, but I wonder a bit about many small scale sysadmins out there using Koha.

Also, as an aside, it is my understanding that these two schemes work in different ways.. cron.d runs more like the original cron and just 'does a thing at time X' where as cron.daily (and friends) uses anacron in the background and as such 'does thing some time after X, with random delay Y and retries if the server is down'.

anacron should never be installed on a server. It's really more suited to desktops and laptops. That said, /etc/crontab will use it if it's present and executable. I'm looking at a customized Debian 9 Jessie and I see anacron installed and executable, and I'm looking at a Ubuntu 18.04 Bionic and I see that anacron is not installed. Sure enough, the Debian Jessie appears to be a Desktop image, while the Ubuntu is a headless server image. I think that actually helps make my case a bit for not using /etc/cron.daily heh. But that's just my 2 cents. It's not a hill I want to die on by any means. Happy for it to go in /etc/cron.daily if everyone else does. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103778|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103775|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #39 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 105401 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105401&action=edit Bug 25245: (follow-up) Use Koha::Logger Update script to use Koha::Logger to capture method failures. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|m.de.rooy@rijksmuseum.nl |tomascohen@gmail.com --- Comment #41 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I think this implementation is simple and covers the use case it is intended to. If we happen to have a task scheduler in a future, we could replace this and many other things we do with cron with it. I don't think the Koha::Logger follow-up should be pushed along with this, as we don't have a 'cron' entry in log4perl. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_05_candidate | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #105400|0 |1 is obsolete| | --- Comment #44 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 106067 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106067&action=edit Bug 25245: Add plugins_nightly.pl cronjob script This script simply iterates through installed plugins that impliment a cronjob_nightly method and runs said method. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #105402|0 |1 is obsolete| | --- Comment #46 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 106069 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106069&action=edit Bug 25245: Add plugins_nightly.pl to the default cron Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #48 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- *** Bug 20897 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #51 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #50)

Could you possibly write an example of how you'd expect a plugin to use the new task queue stuff as an alternative to this? I'm happy for this bug to be replaced with such an example.. right now I don't know enough of how that code fits together to really do such an example myself.

I don't think it's possible at the moment, but here's what I would envision: 1. Have a module/function registry for koha-worker to check when it gets a message 2. A plugin registers a module/function when it's installed 3. The plugin provides an API where it gives an immediate response and stages some data but does the actual processing via the task queue (ie koha-worker) 4. The koha-worker verifies the message against the registry, and invokes the code provided by the Koha plugin I think that Tomas may have had a similar idea? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #53 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #52)

An easy (but lazy) implementation could be: - Have a Koha::BackgroundJob::Plugin - Your plugin class inherit it and has a job_type="plugin|Your::Plugin::Class" - Your plugin implement ->process

You can now call ->enqueue to enqueue the job, and the worker will process it when possible.

Could you elaborate on this part? The koha-worker code would need to be updated to support that job_type="plugin|Your::Plugin::Class", right?

However we don't have the "at" part here, it should be done on a separate bug report with bug 1993 in mind.

I'd love to do a POC for this. I'll comment on Bug 1993. (Now to find the time/energy...)

I think Tomas's idea was to have REST API routes to enqueue new jobs.

+1 I like the idea although we'd want that API route to be private/highly privileged. Otherwise it might be accidentally abused. (I have been thinking how Koha could use a better separation of private/public API routes...) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #55 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #54)

Yes, a task scheduler would be great, but I really didn't want to wait another 10 years whilst people made up their mind on how to implement one.

Very fair point.

Task Schedular != Task Queue

Also very true.

As for the task queue, now I've looked at it.. I'm rather disappointed that it's hardcoded to a list of tasks, doesn't allow for parallelism, doesn't offer retries or failure states, doesn't even allow for multiple workers?

I'm disappointed by the same things, but no one (myself included) was willing to work on those things. That said, it shouldn't be too hard to refactor (brand new code...) to have a more dynamic list of potential tasks and using multiple workers would be fairly trivial to add too. I haven't looked at the code recently enough to remember how it handles retries/failures, but that's something that would be fairly app specific anyway I think, so something that can certainly grow over time. These are changes I want to make at some point, but I don't have the resources to do them.

Perhaps I was spoilt with Minion in previous projects.. personally I would have loved to have simply adopted it..

I wasn't super fond of Minion when it was first mentioned, although recently I was re-reading the documentation and it is more full featured than I originally thought. It probably would have been sufficient. In hindsight, we probably should have gone that route. Considering the "sunk cost fallacy", perhaps we should still go that way. Even in terms of sunk cost, we haven't actually invested too much in RabbitMQ yet. (Regarding RabbitMQ, I like how we can use a standard messaging protocol, which gives us language agnosticism - it would be nice to use more task-appropriate languages rather than just using Perl for everything. I like how it's scalable, although few Koha instances need to scale. These days, you can use a managed RabbitMQ via AWS, so you don't even have to maintain that infrastructure, if you have the budget.)

I thought the biggest thing against it was that it recommends the use or Mojo::Pg as the backend and we use MySQL....

I think that was one of the "cons", but when it was first mentioned I also don't think that Koha had really adopted Mojolicious as fully as it has now. I think there was still a fair bit of skepticism about Mojolicious at that point in time.

what's the difference in requiring people to install RabbitMQ vs requiring them to install Postgres?... there is also a well maintained MySQL backend that implements a clever form of PubSub to get around the fact that MySQL doesn't do pubsub natively.

I think it's a bit absurd to require 2 different relational databases on the face of it, but that's a fair point from a technical perspective. I've noticed the MySQL backend as well and it seems reasonable enough at a glance.

As for a simpler scheduler.. why not just keep a list of tasks and execution times akin to cron in a table and query it every minute.. the exact same way cron does... and leave FIFO tasks to the queue implementation we've now got.

Many years ago, Galen and I talked about keeping a list of tasks and execution times in a table and having a cronjob run every minute to examine the times and run the tasks, but no one got around to doing it. Personally, I'm more ambitious than that now and have had use cases that required scheduling granularity of less than 1/minute. However, my ambitions certainly outstrip the time/energy that I have available. Even though I have the technical ability, I don't have the logistical resources to get it done in a timely way. Now I'm just being pedantic, but the simple scheduler proposal is different to cron. If I recall correctly, cron keeps all the tasks in memory, and it only does I/O when it detects a change to a crontab. But polling a database every 1/minute isn't a drama. It's a scheduler that wouldn't work for some of my use cases, but it would meet the majority of Koha's needs, so it's probably the way to go. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #57 from David Cook <dcook@prosentient.com.au> --- Regarding my above comments, while I have ambitions for a bespoke task scheduler, Martin is correct that it is unlikely that I am going to write such a task scheduler any time soon. (I'm really valuing my work-life balance.) As a result, I suppose I'm open to ideas. This bug is immediately practical. However, it would be nicer to have the plugins use a unified Koha scheduler rather than one special for plugins. To that end, Martin's idea for a database table that tracks tasks and execution time, and then having a scheduler (either cron-based or a separate daemon) to poll that database table for tasks every 1 minute is probably reasonable. I'm not going to work on it, but I can support that idea. It's a fine line between practical and technical debt but... I think we need some kind of scheduling. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #58 from Tomás Cohen Arazi <tomascohen@gmail.com> --- We shouldn't make this tiny but useful enhancement depend on something as big as having the task queue code adapted to handle scheduled tasks, defined by plugins (the background jobs stuff isn't prepared yet to be extended by plugins). It is like requiring we rewrite C4::Search to allow plugins to perform searches. While it would be awesome, it is way too much. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #60 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #58)

It is like requiring we rewrite C4::Search to allow plugins to perform searches. While it would be awesome, it is way too much.

I like the way that you phrased that. While it's great that we have the task queue now, I think that we still have a lot of work to do and it hasn't really been battle tested yet either. Should this go back to "Signed Off" or "Passed QA"? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #62 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Done, thanks for the reminder :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This patchset adds a new release notes| |cronjob script to Koha, | |plugins_nightly.pl | | | |This | |script will check for | |plugins that have | |registered a | |cronjob_nightly method and | |execute that method. | | | |This | |enhancement allows users to | |install and setup plugins | |that require cronjobs | |without backend system | |changes and prevents the | |addition of new cronjob | |files for each plugin. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |21.05.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #65 from Fridolin Somers <fridolin.somers@biblibre.com> --- Should this be backported in 20.11.x ? Its quite standalone so risk is minimum right ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #67 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I'd really like to see it backported. Kinda the point of the plugin system is not to make it necessary to change core code :) And 20.11 is still pretty young, I think it would be a nice addition and there is some history for backporting plugin and REST API things. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #69 from Fridolin Somers <fridolin.somers@biblibre.com> --- I updated https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #71 from David Cook <dcook@prosentient.com.au> --- (In reply to Fridolin Somers from comment #68)

Pushed to 20.11.x for 20.11.03

Woo! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |27820 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27820 [Bug 27820] plugins_nightly.pl script fails with: Undefined subroutine &main::cronlogaction -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #73 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Did you mean bug 27820 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25245 --- Comment #75 from Fridolin Somers <fridolin.somers@biblibre.com> --- (In reply to Jonathan Druart from comment #74)

(In reply to Martin Renvoize from comment #73)

...

Did you mean bug 27820

Yes! Thx

bug 27820 is pushed to master and 20.11.x ouf ;) -- You are receiving this mail because: You are watching all bug changes.