Project

General

Profile

Actions

Bug #25621

closed

Creation of late task

Added by Ingmar Schlecht over 14 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Should have
Category:
scheduler
Target version:
-
Start date:
2009-10-10
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I have a question (or maybe a feature request) regarding the creation of single (not recurring) tasks.

When I enter a date as "start date" that lies in the past, the BE module detects that and on-save changes the record to "disabled". So directly after saving the status of the newly created task is "Disabled, will not be executed, except manually".

Wouldn't it be nicer if it was instead "Late, will run with next execution"? I think people would expect that and also it would be a very convenient way to make tasks execute at the next occasion: Just set the date to something in the past, and it will appear as "Late".

(issue imported from #M12177)

Actions #1

Updated by Francois Suter over 14 years ago

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?

Actions #2

Updated by Ingmar Schlecht over 14 years ago

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.

Actions #3

Updated by Ingmar Schlecht over 14 years ago

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

Actions #4

Updated by Steffen Kamper over 14 years ago

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.

Actions #5

Updated by Francois Suter over 14 years ago

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.

Actions #6

Updated by Francois Suter over 14 years ago

Committed to trunk in revision 6194.

Actions #7

Updated by Michael Stucki over 10 years ago

  • Category set to scheduler
Actions #8

Updated by Michael Stucki over 10 years ago

  • Project changed from 739 to TYPO3 Core
  • Category changed from scheduler to scheduler
  • Target version deleted (0)
Actions

Also available in: Atom PDF