TYPO3 Core

Francois Suter wrote:

It should be possible to disable a registered task without having to delete it altogether or disabling the whole cron job.

Ok, with that in mind #4020 would make more sense, but let's have this one before we discuss #4020 further.

In a setup with a lot of tasks (possibly with a variety of additional fields) it would be a hassle to have to delete and recreate a task just to stop it, and impossible to stop the complete scheduler cron.

A work around would be to change the type from "reccurring" to "single" and set a start date in the past, but this is not convenient.

Seems to be a hack. What about the good old hidden field?

The solution is to introduce a "disabled" field in the database table and add a "Disable/Enable" button in the list view.

Disabled could do it too, but simply saving it into a field called hidden and labeling it disabled would suffice. I also wouldn't add a button to the list view, but rather add a checkbox in the edit dialog.

It should be possible to disable a registered task without having to delete it altogether or disabling the whole cron job.

Ok, with that in mind #4020 would make more sense, but let's have this one before we discuss #4020 further.

Sounds reasonable ;-)

A work around would be to change the type from "reccurring" to "single" and set a start date in the past, but this is not convenient.

Seems to be a hack. What about the good old hidden field?

Definitely a hack, which is why I suggest something else...

The solution is to introduce a "disabled" field in the database table and add a "Disable/Enable" button in the list view.

Disabled could do it too, but simply saving it into a field called hidden and labeling it disabled would suffice. I also wouldn't add a button to the list view, but rather add a checkbox in the edit dialog.

Well, the fe_users and be_users tables have a "disable" field, rather than "hidden". So I would say it's ok to call the field "disable" and it's certainly more representative of its function than "hidden". OTOH "fe_groups" and "be_groups" use "hidden" :-( (so much for consistency).

OK, for not adding a button to the list view. At least it avoids the long-lasting usability problem with the hide/unhide icon in Web > List ;-)

Francois Suter wrote:

Disabled could do it too, but simply saving it into a field called hidden and labeling it disabled would suffice. I also wouldn't add a button to the list view, but rather add a checkbox in the edit dialog.

Well, the fe_users and be_users tables have a "disable" field, rather than "hidden".

I'm fine with disabled then, it's more descriptive about what it actually does.

So I would say it's ok to call the field "disable" and it's certainly more representative of its function than "hidden". OTOH "fe_groups" and "be_groups" use "hidden" :-( (so much for consistency).

;)

I expected to be finished tonight, but I couldn't. I stumbled on the fact that tasks were essentially meant to be stored as serialized objects inside minimal DB records.

There was already an exception made for the CRID information, which has its own DB field. Now the disable information must also have its own DB field and making another exception in handling is not possible as it would multiply DB calls to update the information. So I'm changing the save process to handle that more simply.

Francois Suter wrote:

There was already an exception made for the CRID information, which has its own DB field. Now the disable information must also have its own DB field and making another exception in handling is not possible as it would multiply DB calls to update the information. So I'm changing the save process to handle that more simply.

Hmm, how about adding a property to the object and checking that when running the tasks, something like isDisabled() ...

Somehow I find it more logical and convenient to have the disabled indication be a DB field. It makes it possible to directly select non-disable tasks. Otherwise you would have to select all records, unserialize every object and call isDisabled(). I would say this is a bit too heavy if you have a lot of tasks (I have a live system (with Gabriel) running 30+ tasks).

The downside is that it's a bit confusing what is a DB field and what is a member variable stored inside the serialized object, but I would say it's a lesser evil. And it's why I'm improving the task API so that it's more transparent.

Francois Suter wrote:

Somehow I find it more logical and convenient to have the disabled indication be a DB field. It makes it possible to directly select non-disable tasks. Otherwise you would have to select all records, unserialize every object and call isDisabled(). I would say this is a bit too heavy if you have a lot of tasks (I have a live system (with Gabriel) running 30+ tasks).

I was in the assumption that all tasks would be fetched anyways. so a DB table field would be good then too if that's not the case

Solved in r1111