Bug 7972 - GUI for Crons
Summary: GUI for Crons
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
: 26710 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-17 15:50 UTC by Nicole C. Engard
Modified: 2024-03-12 15:57 UTC (History)
23 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-04-17 15:50:26 UTC
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.
Comment 1 Paul Poulain 2016-06-04 09:05:19 UTC
Removing assignment to me
Comment 2 Owen Leonard 2020-10-16 19:15:29 UTC
*** Bug 26710 has been marked as a duplicate of this bug. ***
Comment 3 Christopher Brannon 2020-10-16 19:43:20 UTC
+1
Comment 4 Barbara Johnson 2020-10-17 14:35:04 UTC
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.
Comment 5 David Cook 2020-10-19 00:41:51 UTC
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.
Comment 6 Katrin Fischer 2020-10-19 00:46:20 UTC
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*.
Comment 7 David Cook 2020-10-19 00:53:08 UTC
(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.)
Comment 8 Katrin Fischer 2020-10-19 00:54:41 UTC
You are right, I missed the point of scheduling them.
Comment 9 Christopher Brannon 2020-10-30 15:15:12 UTC
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.)
Comment 10 Jonathan Druart 2021-05-27 07:08:32 UTC
An eventual implementation for this bug should have bug 1993 in mind.
Comment 11 Daniel Gaghan 2021-06-09 15:29:14 UTC
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.
Comment 12 Rebecca Coert 2021-09-23 20:39:30 UTC
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.
Comment 13 Magnus Enger 2023-03-31 12:17:35 UTC
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.
Comment 14 Ray Delahunty 2023-11-27 11:38:47 UTC
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.