😢 After upgrading from VisualCron 4 to VisualCron 5, the default options on the new "on error" feature cause all of my tasks to work differently than they did under VC4. While the new feature is useful, it would have been better if the default options on this feature allowed the task to operate the same way it had in VC4. Now I have to edit numerous tasks, one at a time, to disable the on error so it won't force a job to stop because a single task has an error. This makes the upgrade very difficult.

1. Please let me know if I'm missing something and there is an easier way than having to edit every task, one at a time. In most cases, I do NOT want the job to stop when a task has an error. I want the next task to run.

2. Please, when adding new features in the future, whenever possible, configure the defaults for the new feature such that VisualCron with the new feature works the same way as prior to the new feature.

3. I would like to have a way to make changes to multiple tasks at the same time.

Hi,

The main problem was that the default behavior of version 4 was wrong. That is why we changed the default behavior in version 5.

1. the easiest way is using the API but that requires programming skills. Otherwise you need to do it manually

2. yes, we try to do this, but in this case default behavior was wrong

3. the big question is how this interface would look? It could get very complex. We only have some (common) properties that active/inactive etc

---

Hi,

The main problem was that the default behavior of version 4 was wrong. That is why we changed the default behavior in version 5.

I have to disagree with your statement that the default behavior of version 4 was wrong. While it may not be the behavior you desired, it was nevertheless the correct behavior for version 4 and the behavior that your customers had available in version 4.

The issue here isn't about whether a feature is a good idea or not; the issue is the process of transition should be to maintain functionality similar to previous versions while offering new features that can be implemented as needed and as time allows.

This new feature (on error), has precluded me from doing the upgrade for at least half a year because I haven't had time to deal with fixing all of the tasks so that an error won't force a job to stop.

One way to handle this is to provide on option during the upgrade (or during import of jobs/tasks) to allow the user to select the default options for features not already implemented in the previous version (or in the import file).

Hi,

3. the big question is how this interface would look? It could get very complex. We only have some (common) properties that active/inactive etc

I think you answered your own question. The idea would be to provide an ability to modify common properties for multiple tasks. The interface needs to protect those items that are not common and allow changes only for the properties common to the selected tasks.

In my observation, there are plenty of common properties and I've had numerous occasions where I had to make the exact same change to multiple tasks.

I realize this would require some effort to implement, but I think it is worth considering.

In early 4 versions it had the same behavior as in version 5. A bug slipped through that caused the error validation to fail. That is why we corrected this.

I agree with you that it would be nice with upgrade options. This case it not normal, because we normally uses the same behavior, unless we find it a bug.

In this case we chose not to put any time into the upgrade process as it would take some time to make a generic interface. We considered the problem very small as you can easily change this value. I agree that if you have many Tasks it could be tedious.

We always fight with resources and prioritization and we keep a high degree backward compatibility. In this case we did not think of it as a problem and spent time on new functionality instead. We are sorry for the inconvenience in this case.

---