[ENHANCEMENT]: redesign TaskWrapper, SuperTask, Task

[rixvet]

Description

Inspired by #906 let's think about:

Currently there is only a Task endpoint, but when you for example set the priority of the Task you are not setting it of the TaskWrapper. But the TaskWrapper is used to determine the real priority.

I do think it needs some rethinking though, since we are traversing multiple models objects within an object. It almost feels like it needs 'hide' the taskwrapper, behind regular Task/Supertask objects, how-ever this is currently blocked because of the Supertask object being 'abused' as SupertaskTemplate (#918).

When thinking about dropping TaskWrapper in favor of two separate entities. Since the implementation of 'Task' (which might be an supertask, and the TaskWrapper as an, ehm, 'wrapper', makes the whole behaviour rather confusing.

Let's think conceptually. We have something correspond to a single task and the other thing which corresponds to a 'group of tasks'. We also have have an 'template for tasks' and 'template for a group of tasks'.

Current implementation

• 'single task': Task
• 'group of tasks': 'special' Task (e.g. mangling with TaskWrapper et. al)
• 'template for tasks': PreTask
• 'template for a group of tasks': SuperTask

Re-design considerations

• Avoid 'rebranding' objects, since this will cause highly confusing behaviour both in communication and development.
• Avoid model change behaviour based on fields of the model.

Future

• 'Task' is clear, if an user creates an Task, it expect this to be an single task.
• PreTask is not clear, it sounds like something which needs to be done before an Task is executed (think of PreProcessor). More-over one can argue it makes more sense to call an Task template 'TaskTemplate'
• SuperTask is not clear, it does not imply 'template' of 'pre' anything. From first glance one would expect it to be 'running SuperTasks'. Renaming it to 'SuperTaskTemplate' makes more since. Conceptually.
• SuperTask (as in running SuperTask) is the one which is going to cause issues, since it was first reserved for the template and should now be used for the running supertask instead.

Alternative naming SuperTask
To avoid confusion an alternative name can be considered, some alternatives:

• TaskGroup (potentially confusing: Group in context is now used for 'group of users' or 'group of agent' which is entity based)
• TaskCollection
• MultiTask
• TaskList
• MegaTask

Sentences to consider, which should make a nice ring to it:

• Apply to hashlist'
• Add TaskTemplate 12 to Template'
• Raise priority of 123 to 100'

[s3inlc]

I think this is a discussion we definitely need to take into account. But I guess we will not be able to solve these "legacy" issues before we remove the old UI, otherwise we would have a rather load of work to do there as well to change it.

There is one small note regarding what you mentioned on the current situation:

When thinking about dropping TaskWrapper in favor of two separate entities. Since the implementation of 'Task' (which might be an supertask, and the TaskWrapper as an, ehm, 'wrapper', makes the whole behaviour rather confusing.

A Task in the sense of the DB table can never be a running Supertask. That's the idea of the TaskWrapper, so in case there is a Supertask, the wrapper "is" the running Supertask and all the tasks belonging to it are the subtasks of that Supertask. With having a TaskWrapper also for the normal tasks, it makes it always having the same hierarchy, and therefore easier to handle when deciding which task (by looking at it's TaskWrapper) has the next highest priority.

We already spoke about this, the naming is definitely far from optimal, especially the Supertask parts, this has to be changed at some point. I like your proposal of 'TaskCollection', it causes not any confusion with existing names and still quite clear says what it is.

[zyronix]

I am trying to get some feedback from other via discussion to vote for that naming of the TaskWrapper stuff:
#1005