One thing that our current "1-click child tasks" component does well (that has a number of other issues and we'd love this to replace it) is allowing us to setup a number of tasks in order
i.e we want "heal effect of bug" bug only task to be before shared "orientation and task estimates" and that before bug only task "add PostDeploy to remove DisableDoParameter".
I mentioned this way back in the now closed #1
The problem with the current implementation is that we either have to have
2 separate groups of task e.g. "Bugs", "PBIs" with duplicate tasks for each one where they both need the same. This means that we have to copy and paste the same tasks across which is difficult to maintain.
OR we could have 3 separate groups "Shared", "Bug tasks only" and "PBI's tasks only" BUT there is no way to ensure that the "Bug tasks only" are ordered appropriately alongside the "PBIs tasks only". Today it would result in the Bug Only tasks to be grouped together and the Shared tasks to be grouped together incorrectly.
Today our only practical option is the first one with the overhead that this brings
It would be great if we could either
Indicate a constraint on each Task to indicate the "workItemTypes" that this would be created on. This way we would just have a single group "Bugs/Pbis" and then appropriate tasks would be created in the given order
Have a way to indicate ordinal
option 1 is much more preferable as it would be much easier to maintain and intuitive to understand what would happen
One thing that our current "1-click child tasks" component does well (that has a number of other issues and we'd love this to replace it) is allowing us to setup a number of tasks in order
i.e we want "heal effect of bug" bug only task to be before shared "orientation and task estimates" and that before bug only task "add PostDeploy to remove DisableDoParameter".
I mentioned this way back in the now closed #1
The problem with the current implementation is that we either have to have
Today our only practical option is the first one with the overhead that this brings
It would be great if we could either
option 1 is much more preferable as it would be much easier to maintain and intuitive to understand what would happen