Great work, some ideas

[o-o00o-o]

Hi, ADO desperately needs a way to create child items from master templates so great that someone else is working on this. Right now 1-click-child tasks extension seems to be better suited for us for the following reasons

1. Easier to setup templates using the templates area rather than creating json from scratch.
   • This also means that the templates are available via the UI templates area also if you want to update existing ones.
   • Don't need to know the system field names etc.
2. Able to setup seperate teams with seperate stack of templates. We use this to have a release, GetReady and Dev teams all have their own set of default tasks

Things that I would really like to see added would be A. able to build sets of tasks with a name that can be picked at runtime. I can imagine that some way of indicating in the template description (e.g. #CsharpDevTasks or #PowershellDevTasks could provide the list of groups to select). B. 1-click-child-links allows you to select which tasks will be created from each different parent type. It even works for Features/PBI's which is really useful. C. 1 click-child-tasks is flakey unless you run it from the card view, it would be good if this could be done from the list view also

[JonathanLascaux]

Hi and thank you for your comment !

A - we consider this and yes we also want to have an option to select at runtime "which" template to run. We don't have a delivery date but it will be in the next updates for sure B - Do you have an example ? I feel it's like the remark A no ? C - Can you show me from which view exactly ? It's not available from the "work items" view due to the way DevOps displays the info, but from the other ones it's generally speaking available.

Thank you for your feedbacks, it's helpful !

Jonathan Lascaux

[jpiquot]

Hi thanks for you feedback,

I did not use task templates as I wanted to be able to reuse the informations that are in the parent ticket. You can use string interpolation to have for example a DEV task that have the same subject than the parent.

It is a good idea to use WIO templates. I can add a "Template" parameter where you can get the task data from a DevOps template but still been able to override data as defined now.

{
  "tasks": [
    {
      "name": "Design Task",
      "template":"Team/MyTemplate1"
      "fields": [
        {
          "name": "System.Title",
          "value": "{System.Title} test child task for {id}"
        }
      ]
    }
  ]
}

[o-o00o-o]

Hi and thank you for your comment !

A - we consider this and yes we also want to have an option to select at runtime "which" template to run. We don't have a delivery date but it will be in the next updates for sure B - Do you have an example ? I feel it's like the remark A no ?

So we have some task templates that run for Bugs, and some that run for PBI's and some that run for both. e.g. Here are 3 templates that we have

Task1, [Bug], Heal effect of bug Task2, [Product Backlog Item]. PBI Orientation Task3. . Complete PR

Due to the constraints in the second field (Template Description) Task1 is only generated if created from Bug, Task2 only generated for a PBI and Task3 is created from both (as there is no Item Type constraint

The benefit of this is that we have a DRY implementation for Task 3 rather than having 2 template sets both with their own version of Task3

C - Can you show me from which view exactly ? It's not available from the "work items" view due to the way DevOps displays the info, but from the other ones it's generally speaking available.

Card view is when you click into a work item and you see only the details for that card List view is when you view a list of items. e.g. the backlog.

1-click-child-tasks shows an options on the ... menu in both places but only the Card method is reilable

[o-o00o-o]

Hi thanks for you feedback,

I did not use task templates as I wanted to be able to reuse the informations that are in the parent ticket. You can use string interpolation to have for example a DEV task that have the same subject than the parent.

1 click child tasks does this by simply copying the parent value if you don't specify

"iteration path" and "assigned to" will be copied from the parent when called with 1-click-child-tasks

it will also allow you to put string interpolation in the fields also as a token that is replaced during execution time

Note that the [Ignore] in the description is how 1-click-child-tasks decides if it will create the template as part of the "create-tasks" item on the ... With [Bug] in the description it will only create this tasks if created from a Bug, [Product Backlog Item] it will only create for a PBI, [ignore] doesn't exist as a work item so it will never be created. This is useful as it allows reuse of tasks between different item types

It is a good idea to use WIO templates. I can add a "Template" parameter where you can get the task data from a DevOps template but still been able to override data as defined now.

{
  "tasks": [
    {
      "name": "Design Task",
      "template":"Team/MyTemplate1"
      "fields": [
        {
          "name": "System.Title",
          "value": "{System.Title} test child task for {id}"
        }
      ]
    }
  ]
}

This has now put the information in two different places which I'd suggest is a worse user experience. I think you could adopt the same way of string interpolation as 1-click-child-items does.

The problems with the json-first approach is that

1. it is much less friendly to build new templates. Right now we can create a new template based on an existing item with built in functionality. Available fields are automatically available and we don't need to try to work out what the correct field name is

2. it is not compatible with the existing engines which means it is much more difficult for us to switch between different engines to try them out. I have over 100 templates across 3 teams. Not trivial to try this out for a sprint to see if the team likes it.

3. It means that if we want to update a template, but there are existing in-flight items in place, it is much more difficult to update them. With the template method, we can just go to each item and re-apply the template using the built in ... menu.

I'd urge you to extend in the direction of using the built in UI to get these benefits

In addition, here are some things that the current engines don't work well with and your tool could become the solution to these

4. Current engines link the template set to the current team. This makes it complex to use as you have to be in the correct backlog to be able to instantiate the tasks. It would be better to allow all team templates to be considered and have a different approach to group them than teams (e.g. hash-tags in the description/comment etc) - then allow the user to pick any of the task template groups at runtime regardless of the team that they are currently in

5. It would be great to be able to backup and restore the current capture the current templates into a json document (and back again) would be really useful. This would allow us to source control our templates etc

6. Tasks can get created with no parent if executing in list view with a large number of child tasks) (as per my previous post)

Hope this is helpful

[jpiquot]

Hi,

Thanks for the very detailed informations.

1) Ok to use interpolation inside the WI template. 2) I think we will need a json file to at least define template groups and filters

{
     "templates": [
         {
             "name": "My Bug Tasks",
             "project": "myproject", // apply to only one project
             "workItemType": "bug", // apply to bug parent work items
             "templates": [
                 "proj1/Team/Task1",
                 "proj1/Team/Task2",
                 "proj1/Team/Task3",
                 "proj1/Team/Task4",
              ]
         },
         {
             "name": "My Tasks",
             "project": null, // apply to all projects
             "workItemType": null, // apply to all work item types
             "templates": [
                 "proj2/Team/Task1",
                 "proj2/Team/Task2",
                 "proj2/Team/Task3",
                 "proj2/Team/Task4",
                 "proj2/Team/Task5",
                 "proj2/Team/Task6",
              ]
         }
     ]
}

[jpiquot]

Hi, some users prefer to use the JSON version of the setup than using DevOps templates. As, there is already an existing extension based on those templates, we will keep the JSON setup for the moment. A new version this week will contain multi selectable templates to add more flexibility.

[jonalexharbor]

"iteration path" and "assigned to" will be copied from the parent when called with 1-click-child-tasks

Hello. I'm not sure if this is the right place to ask this but I was wanting to get the parent "Assigned To" value to be inherited by the child task. I noticed this comment in my search and I want to ask whether this behavior is being suggested, or if it's already part of the solution.

I thought I'd be able to use something like this, similar to the System.IterationPath and System.AreaPath variables: { "name": "System.AssignedTo", "value": "{System.AssignedTo}" },

But this seems to prevent the tasks from generating.

In any case, this extension looks to be very useful and will save us time as-is. Inheriting the assignee of the User Story would be fantastic.