It would be awesome if in the Admin area there was a way to turn on/off cron jobs and set the timing on them. I've seen GUIs like this before so I know it can be done, just not what it would take to do it. Obviously such a feature would be a permission associated with it so that not everyone could go in and screw with things.
Removing assignment to me
*** Bug 26710 has been marked as a duplicate of this bug. ***
+1
We would like this functionality as well since it would provide libraries more control over this process. Besides the name of the cron job, whether to run or not and the timing, I think it would be a good idea to have a description of what the cron is supposed to do and a notes field where libraries could enter local information specific to each cron job.
I don't think that this is practical. Generally speaking, cronjobs are really handled at the system administration level rather than the application level. With Koha Debian packages, there are cronjobs deployed out of the box, but they're not manageable by the Koha instance. I suppose the cronjobs could be re-engineered, at least for the Koha Debian packages, but then that becomes a logistical problem for system administrators. That being said, there is more work being done in terms of background tasks. What kind of cronjobs do people have in mind here? It could be more practical to move some functionality from cronjobs into a different kind of scheduled task.
Some of our cronjob scripts are already controlled by system preferences. I think that would be the easiest way to move on here: Schedule them all by default for all instances, but allow libraries to configure (and turn off by configuration) using system preferences or possibly a separate page. Examples would be the *LongOverdue prefs*.
(In reply to Katrin Fischer from comment #6) > Some of our cronjob scripts are already controlled by system preferences. I > think that would be the easiest way to move on here: Schedule them all by > default for all instances, but allow libraries to configure (and turn off by > configuration) using system preferences or possibly a separate page. > > Examples would be the *LongOverdue prefs*. Could you clarify what you mean? I think Christopher and Barbara were referring to changing the time that the cronjobs run? (For instance, as a vendor, we only run /usr/share/koha/bin/cronjobs/process_message_queue.pl between certain hours so that we're not sending emails out in the middle of the night. I could see libraries wanting to do that.)
You are right, I missed the point of scheduling them.
Our primary concern is not only being able to adjust the frequency and between what hours a cron might run, but also being able to see what all is running, and when. As a consortium admin with a support vendor, we are blind to these settings, and would like to be able to see how things are set without having to ask the vendor to dig all this information up. I think some things might need to be untouchable, and only visible, and others need to be both visible and adjustable. They should also only allow you to adjust them within certain limits, so as not to bog down the system or make it unstable (i.e. telling the system to reindex hourly would be a bad option. - I'm guessing - what do I know? I can't see these things.)
An eventual implementation for this bug should have bug 1993 in mind.
Having this enhancement would be a big help. Scheduling crons is not the biggest need for us (PCCLD) right now. However, knowing if the report is running or if it failed is, IMHO. So I would vote for a GUI that shows the name of the report, when it's scheduled for, when it was last ran and whether it failed or not.
It would be very helpful to have this feature - both the scheduling ability and the cron status view. This would be very useful if we need to adjust our settings quickly for some reason.
In the meantime, CronjobLog was added, which at least makes it possible to see what cronjobs have been run. This does not fix the problem of seeing what jobs will be run in the future, or controlling them, of course. Bot sure if we should mark bug 24968 as a duplicate of this bug, or the other way around.
In reply to David Cook in Comment #5 > What kind of cronjobs do people have in mind here? We are making increasing use of patron_emailer.pl released in Koha in 19.05 and to a lesser extent runreport.pl and having these able to be managed by library staff would be great. We don't have access to the server and have been told by our support company that write access to the cron is not an option for us.