zentralopensource / zentral / 31176520214

90%

push

github

turbo: fix what a schedule delivers at creation

The done-gate is keyed on the OneTimeJob, not on the job it points at:
ConfigView stops serving a one-time job to a machine as soon as that
machine has a last_result_at, whichever job produced it.

Re-pointing an existing one-time job at another script or mSCP check
therefore left every machine that had already run the old one marked as
done, and the new job silently never ran there. It only reached the
machines that had not completed the old one yet.

Pin the job the way the configuration is already pinned. The form
disables the field and rejects a posted one: disabling alone is a silent
no-op, since the browser drops the field and Django ignores whatever
arrives, so a client that meant to change the job would have seen a
successful update that changed nothing.

Recurring jobs are pinned too. Nothing gates on RecurringJobMachine, so
a swap there is not the same silent delivery hole -- the new job is
served to everyone on the next check-in and the rows converge -- but it
mixes two jobs' version numbering in one ledger, and having the two
schedule types disagree on what is editable is its own cost.

The recurring duplicate-job check goes with it. It only ever fired on an
update: a creation cannot reach it, since the form already keeps the
scheduled jobs out of the choices, and a schedule that keeps its job can
only collide with itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

11 of 0 new or added lines in 0 files covered. (NaN%)

50071 of 55858 relevant lines covered (89.64%)

0.9 hits per line