{"id":59855,"date":"2020-10-07T05:30:03","date_gmt":"2020-10-07T13:30:03","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/devops\/?p=59855"},"modified":"2020-10-07T07:57:58","modified_gmt":"2020-10-07T15:57:58","slug":"removing-assigned-to-rule-from-bug","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/removing-assigned-to-rule-from-bug\/","title":{"rendered":"Removing Assigned To Rule from Bug"},"content":{"rendered":"

In Azure DevOps, there are many hidden state transition rules scattered across the different work item types. These rules are system generated and cannot be edited or removed. Most of them are necessary to track when a work item is activated, resolved, or closed. For a few of the rules, the value is less obvious, and in some cases are a cause of customer dissatisfaction with the product. Even though they made sense years ago, these rules have outlived their usefulness and it is time for them to be removed.<\/p>\n

In this blog post, we wanted to share the impact of the first rule being removed. We also have a work around for those customers who still want to use the rule in their projects.<\/p>\n

Assigned To rule<\/h4>\n

Although there are several hidden system rules across the different processes (Agile, Scrum, CMMI), the one rule that gets the most negative feedback is on the Bug work item type in the Agile process.<\/p>\n

This rule states..<\/p>\n

When<\/strong> the bug moves to Resolved then<\/strong> automatically set the Assigned To value to the person who created the work item<\/em><\/p>\n

\"Image<\/p>\n

On the surface it makes sense to assign the bug back to the person who created it. They need to validate the bug is fixed. But in reality, teams don’t always work this way. Because bugs are a heavily used work item type, it makes sense to remove this hidden rule and keep things simple.<\/p>\n

This is the first rule to be removed.<\/p>\n

Customer impact<\/h4>\n

The rule will be removed from the Bug work item type in the Agile template starting in the Sprint 177 deployment (starting the week of October 19th, 2020). All projects using the system Agile process or an Inherited Agile process will be affected. Once the deployment reaches your organization, the rule will be removed from all bugs on all projects.<\/p>\n

If you are using Hosted XML, no changes will be made to your process templates and the behavior on the bug work item type will not be affected.<\/p>\n

Using a custom rule<\/h4>\n

For customers who like having bugs automatically assigned to the person who created them, you can create a custom rule. To do so, make sure you have created a custom inherited agile process<\/a>. Then go into the Bug work item type and create a new rule<\/a>. Below is a screen shot of the specific rule you can use to set the Assigned To value to Created By when the state is changed to Resolved.<\/p>\n

\"Image<\/p>\n

Other rules<\/h4>\n

This is the first rule we are going to remove. It is by far the most problematic for customers. We would love to hear your feedback on what other rules are causing you pain and why. Based on that feedback we are open to removing them in future sprints.<\/p>\n","protected":false},"excerpt":{"rendered":"

The hidden rule that assigns the bug to the person who created it when the state is changed to resolved, is about to be removed from the Agile process. In this blog post, we wanted to share the impact of this change as well as the work around for those customers who still want to use the rule in their projects.<\/p>\n","protected":false},"author":921,"featured_media":59249,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[227,229,1],"tags":[],"class_list":["post-59855","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","category-community","category-devops"],"acf":[],"blog_post_summary":"

The hidden rule that assigns the bug to the person who created it when the state is changed to resolved, is about to be removed from the Agile process. In this blog post, we wanted to share the impact of this change as well as the work around for those customers who still want to use the rule in their projects.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/59855","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/921"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=59855"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/59855\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/59249"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=59855"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=59855"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=59855"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}