Bug 24968 - Add system preference controls for cronjobs
Summary: Add system preference controls for cronjobs
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-24 14:59 UTC by Nick Clemens
Modified: 2024-02-26 09:45 UTC (History)
22 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 Nick Clemens 2020-03-24 14:59:29 UTC
At the simplest it would be nice to have an on/off switch for any cronjob so that libraries can disable cronjobs as needed (during emergency closings etc.)

At the most advanced, it could offer the option of controlling all of the parameters for the cronjob, either using a syntax or a new administration area
Comment 1 Katrin Fischer 2020-03-24 15:01:14 UTC
+1
With mulitple instances on one server I'd really love that. Turning things off for just one instance is painful otherwise if you are using for-each.
Comment 2 Martin Renvoize 2020-03-25 12:10:38 UTC
Nice!
Comment 3 Magnus Enger 2020-03-25 12:18:08 UTC
(In reply to Nick Clemens from comment #0)
> At the most advanced, it could offer the option of controlling all of the
> parameters for the cronjob, either using a syntax or a new administration
> area

Or just use sysprefs for the parameters? Anyway, +1000 for this! :-)
Comment 4 Magnus Enger 2020-03-25 12:19:22 UTC
Duplicate of "Bug 7972 - GUI for Crons"?
Comment 5 David Cook 2020-10-27 22:33:50 UTC
(In reply to Magnus Enger from comment #4)
> Duplicate of "Bug 7972 - GUI for Crons"?

Hmm possibly. That bug seems to want to have full crontab access from the web, especially in regards to time scheduling, which sounds terrible to me as a vendor. But maybe I was misinterpreting the comments there.

Nick's suggestion seems to be more about just enabling/disabling and configuring scheduled tasks, which sounds good to me. It wouldn't actually affect cron's operation. Rather, it would affect the scripts executed by cron. Much more reasonable.

I suppose an easy way to bolt this on would be to expand Koha::Script (or a Koha::Script::* module). There could be an "is_enabled" function, and a "get_script_config" function. 

(Regarding Bug 7972, you could perhaps have some config that prevents the script from running during certain times. I think process_message_queue.pl runs every 15 minutes, but we've hard-coded our crontab to only run between 8:00-20:00 so emails don't go out late at night. With this feature, a library could designate their own "do not run" hours. Of course, this would only work if the cronjob is ordinarily set to run during those "do not run" hours, if that makes sense.)
Comment 6 David Cook 2020-11-19 05:51:44 UTC
I'm bumping into this with "/usr/share/koha/bin/cronjobs/membership_expiry.pl" where 1 library wants to send notices to only some categories.

In the past, we added a --category option, but that only worked when we set up cronjobs per-library instead of using koha-foreach. 

I think that I'm just going to use a local system preference here and a local code customization, but it would be useful for libraries to be able to define their own parameters via the web UI for this cronjob...

Really this is a "scheduled task" issue. Not just "cronjobs". In the future, we may have other schedulers in addition to the cron daemon. So whatever solution we come up with... it should be fairly extensible. 

Scheduled Task:
Name: MembershipExpiry
Args:
  Categories: ['Staff','Students','Administrators']
  Branches: ['CPL','MPL','QPL']
  Letter: 

A cronjob could fetch using my $task = ScheduledTask->GetByName('MembershipExpiry');

You could even arguably add "Min time interval" (maybe the cronjob runs every 15 minutes but you only want the job to run no faster than 1 time per hour) and "Last run" to try to control timing a bit... 

Anyway, just some thoughts
Comment 7 David Cook 2021-05-26 00:47:53 UTC
And now I'm noticing that unverified self-registrations aren't deleted by cleanup_database.pl unless you specify "--del-unv-selfreg X" and that's not a default for Koha, even though the default text for OPAC_REG_VERIFY says that unverified registrations "will expire shortly".
Comment 8 David Cook 2021-05-26 00:58:08 UTC
(In reply to David Cook from comment #6)

> Really this is a "scheduled task" issue. Not just "cronjobs". In the future,
> we may have other schedulers in addition to the cron daemon. So whatever
> solution we come up with... it should be fairly extensible. 
> 
> Scheduled Task:
> Name: MembershipExpiry
> Args:
>   Categories: ['Staff','Students','Administrators']
>   Branches: ['CPL','MPL','QPL']
>   Letter: 
> 

If we're going to use system preference though, it makes sense to group them in with their relevant areas... like "Self Registration".
Comment 9 Martin Renvoize 2021-05-26 10:26:38 UTC
I'd forgotten about this bug.. I'd love to see this move forward.. no idea if/when I'll have time to work on it.. but still think it's a great idea.
Comment 10 Magnus Enger 2023-03-31 13:10:35 UTC
Thinking a bit about this at the end of the hackfest...

Question: Do we want the sysprefs or the command line options to "have the last word"? 

One of the arguments for having sysprefs is that we could run the cronjob with 
koha-foreach, and still have different choices for different libraries. So that
would indicate that sysprefs should "have the last word". 

Then there is the question of how to implement this. We could have one syspref
per command line option, and do something like this:

exit unless C4::Context->preference('CronAutomaticRenewalsActivate');

my ( $help, $send_notices, $verbose, $confirm, $digest_per_branch );
GetOptions(
    'h|help' => \$help,
    's|send-notices' => \$send_notices,
    'v|verbose'    => \$verbose,
    'c|confirm'     => \$confirm,
    'b|digest-per-branch' => \$digest_per_branch,
) || pod2usage(1);

$send_notices      = C4::Context->preference('CronAutomaticRenewalsSendNotices');
$verbose           = C4::Context->preference('CronAutomaticRenewalsVerbose');
$confirm           = C4::Context->preference('CronAutomaticRenewalsConfirm');
$digest_per_branch = C4::Context->preference('CronAutomaticRenewalDigestPerBranch');

This would introduce a lot of new sysprefs, and we would have to add a new syspref
when a new command line switch was added. On the other hand it would be easy to 
add descriptions for each setting, and link to related sysprefs. 

Another approach could be to have two sysprefs per cronjob, one to turn it on
and off, and one to do the configuration. This could be done with YAML:

send_notices: 1
verbose: 0
confirm: 1
digest_per_branch: 0

Then we could perhaps do something like this:

$send_notices = get_cronjob_setting( 'CronAutomaticRenewals', 'send_notices' );

This way we could add new command line options without adding a new syspref, 
but editing YAML in a text field might not be the most user friendly interface.
Are there other syntaxes that would be as flexible, but more user friendly?

There there is of course the possibilty of some whole new tool to edit the
options, but that is not something to think about at the end of a hackfest...
So just some thoughts to get the ball rolling and try and provoke folks to 
come up with better ideas  than mine. :-)
Comment 11 Christopher Brannon 2023-03-31 14:25:16 UTC
(In reply to Nick Clemens from comment #0)
> At the simplest it would be nice to have an on/off switch for any cronjob so
> that libraries can disable cronjobs as needed (during emergency closings
> etc.)
> 
> At the most advanced, it could offer the option of controlling all of the
> parameters for the cronjob, either using a syntax or a new administration
> area

+1
Comment 12 Andreas Jonsson 2024-02-23 07:46:42 UTC
How about an administrative interface for scheduling background tasks?  We could integrate an existing crontab web interface such as crontab-ui: https://github.com/alseambusher/crontab-ui and, for security, add access control against whitelisted scripts and configurations.
Comment 13 Martin Renvoize 2024-02-23 16:13:17 UTC
More work required still as it's an unfunded piece.. but I do have the beginnings of a plugin for a "crontab manager" over at https://github.com/PTFS-Europe/koha-plugin-crontab

I still think making our cron scripts all use preferences for their option rather than requiring lots of options be passed in the command line is a good thing though too