TYPO3 Core

I'm not sure how to best answer that. The logic for recurring tasks is that the next execution will always be calculated so as to be in the future. For single tasks, their date should be set in the future "manually" since there's no calculation.

Note that your remark raises at least one problem: when creating a new task, the default date and time defined using $GLOBALS[EXEC_TIME]. If the task is saved without changes, it will set the date in the past, if only because at least a few seconds will have elapsed in the meantime. For recurring tasks, this doesn't matter as a next execution date is calculated, but for single tasks it comes to the behaviour you're describing: the task is late and disabled.

Maybe the following could be a solution: when a new single task is created, the datetime is checked upon saving. If it is in the past, it is changed to be one minute in the future, so that it doesn't get disabled.

This would be the simplest solution. Chaging the automatic disabling of tasks would be more complicated and it is quite a useful mechanism I think.

What do you think?

Actually, I don't understand why tasks are automatically disabled at all. When the date is in the past, well, then it could just be considered a "late" task and executed at the next occasion.

I think when the user wants to disable the tasks, she would just do that. But why would she want the system to automatically disable it?

Regarding the problem you mentioned, I think that wouldn't exist any more when getting rid of the automatic disabling, would it?

I think the bahavior regarding recurring tasks is fine though.

@Francois Suter, I just uploaded the second patch I created during out phone call yesterday, so it doesn't get lost.

isn't it much simpler to validate the date and display a extJs msgbox if date is older than now? This wouldn't allow to create dates lower now.

Here's the formal patch for this issue, which I'm going to submit to the core list.

The main difference with Ingmar's patch (except for more comments) is that the isNewSingleExecution flag is set to false the next time the next excution time is calculated. Otherwise, the task is a new single execution forever.

@steffen: sure, validations could be added, but this bug highlights a fundamental logic flaw, which must be addressed. It should be possible to create single-running tasks with a date set in the past and expect them to be run once. Potentially a task could be created from somewhere else than the BE module.

Committed to trunk in revision 6194.