So, we all adore the way that Azure DevOps allows us to manage engagements (ADO). On Kanban boards, we may make Epics, Features, and User Stories and monitor our progress. Work item types can easily be modified to meet the demands of your company and project. What would happen if you wanted to use a work item type you produced for one business case but clone it for another? The existing work item cannot be copied to a different work item type. It's not a big deal if you only have a few fields, but if you have several pages, various groups on each page, and numerous fields in each group, the effort becomes enormous.
In this article, I'll describe how to use the Azure DevOPs APIs to replicate a work item. The documentation explains the fundamentals of introducing a new process, a work item type, groups, and other things, however there are a few items lacking.
The code is organized in this manner. Before going into the code, I reasoned that it could be beneficial to grasp the flow.
1.Make a fresh work item type
2.By iterating through the target work item type and adding any missing pages, you can create pages for new work item types.
3.Create stages for a new sort of work item.
-Remove any default stages not in copy from work item
4.Each page of the targeted work item type in a loop
-cycle through each page's sections through each group in each part in a loop
- Repeat the loop for each control in each group.
- New work item type field addition (a control holds only 1 field from what I have seen)
- To a specified section, add a group
- Add the control to the given group.
You must then add the stages from the work item you are copying from to the new work item type after it has been created. You will then receive the fundamental Work Item type with the states from the Work Item Target appended. The work item type has one page and four sections by default after it is created. The first three portions, which run from left to right, correspond to the page's three columns. The meaning of the fourth section is still a mystery to me. The addition of the work item categories facilitates the addition of the fields to some extent. Simply add the fields by iterating over each page in the layout.
This puzzle has a few undocumented elements that need to be addressed, and several field types need special consideration. The System by default. The page for creating work items now includes a description area. You must approach this field differently from the others if you for some reason renamed that field. The first group in the first section will be the Description field. The biggest insight was also the most difficult to find. The description field does not have a group when you look at the UI, which is the cause. So, the fact that it is a multi-line text box is the underlying problem here (HTML).
Consider the multi-line text box that is located elsewhere on the page. Remember that everything must be in a group, yet when you look at this field in the UI, it is not. So, after spending a few hours poring at fiddler traffic, I discovered what was missing from the documentation in regards to multi-line text fields. The multi-line field must be added as a control to a group that has already been created. I was lacking a piece of the puzzle, and this was it. When a multi-line field appeared on the page, a request was issued, and I was able to identify it and determine where it was heading.Granted, the documentation on creating a group demonstrates that a control can be a part of the request, but it is silent on the fact that multi-line text fields are an exception.
I intend to address the remaining details in the next article.
Top comments (0)