In DevOps, I need a field which can be a counter and get incremented +1 whenever the work item state change from "Done" to "In progress". I tried to have an integer field and set the Rule as mentioned below
condition: when a work item state changes From "Done" to "In Progress"
Action: Set the value of "Field" to "+1".
This rule is changing the value of the counter from 0 to 1 for the very first time only. However the counter does not keep incrementing whenever I change the work Item state from "Done" to "In progress"
Please suggest me an approach to do it.
I have a similar use case: counting the amount of times a work item fails testing (gets moved back from Resolved to Active). Since I don't need a true increment, just want an indication whether this has happened once, twice, thrice or more, I made a couple of rules, one for each increment, like this:
It won't help in any increment scenario, but possibly it helps some people.
Azure Devops does not support increments. You can try to use:
TFS Aggregator (Web Service).
Create rules with Azure Logic App. It contains triggers and methods to update work items.
Create a custom application. Add field like "Need Increment" with default value "false". Create Rule - condition: when a work item state changes From "Done" to "In Progress" Action: Set the value of "Need Increment" to "true". Your custom application updates you increment field and set "Need Increment" to "false".
Related
Context
I want to create a Power-Automate flow that automatically creates a sub-task in Azure DevOps when the Effort of a PBI is set.
When the Effort field goes from blank to a positive value, the task should be added (using the newly set Effort value as the task's Original Estimate and Remaining Work).
I managed to create a flow that does that using When a work item is update trigger.
Problem
The flow runs too often (whenever the work item changes, as long as the Effort is > 0).
Question
What would be the best way to ensure this flow runs only once per PBI?
Thoughts
Perhaps check for the presence of child tasks?
Perhaps set a hidden property when adding the task the first time and check that property afterwards?
You could add a trigger condition to the settings of your trigger action. Use the following expression:
#greater(triggerOutputs()?['body/fields/Microsoft_VSTS_Scheduling_Effort'], 0)
Add a Send an HTTP request action directly after the trigger. Use the following URI:
YourProjectName/_apis/wit/workItems/#{triggerOutputs()?['body/id']}/updates?api-version=6.0
Add a Filter Array. Use this expression for the From
body('Send_an_HTTP_request_to_Azure_DevOps')['value']
In the where of the Filter Array use the following expression which you add via the advanced mode:
#greater(length(string(item()?['fields']?['Microsoft.VSTS.Scheduling.Effort']?['newValue'])), 0)
In a condition check if the Filter Array returns no results. If it does, the value of Effort has not been changed in the past and you can safely create your new task
length(body('Filter_array'))
is equal to 1
I have a trigger with:
PROBLEM event generation mode: Multiple
OK event closes: All problems
That trigger fires at the expression for the trapper item, which's updated by the crontab multiple times a day. Every time trapper gets a new value, it should be reported by the alert (cause' every time it gets a different value, which is important). But when it's OK, one message should be enough.
Action has "Send message to user groups" operation with a single step, "Immediately" start option and "Default" step duration (3600s).
Recovery operation set to "Send message to user groups" option.
Action also has only folowing conditions in the drop-down:
Application
Host
Host group
Maintenance status
Tag
Tag value
Template
Time period
Trigger
Trigger name
Trigger severity
What may be the reason for multiple duplicating alert messages with OK status, coming at the same moment from the same trigger (and the same alert)?
Have you tried global event correlation ?
It is possible to correlate events created by completely different
triggers and apply the same operations to them all. By creating
intelligent correlation rules it is actually possible to save yourself
from thousands of repetitive notifications and focus on root causes of
a problem!
https://www.zabbix.com/documentation/3.4/manual/config/event_correlation/global
Is it possible to create a rule for a Task transition that would require to change the "AssignedTo" field? Does not matter to what user, just not to the same as it was before the transition. I have tried to add an "EMPTY" rule for the transition and a "REQUIRED" for the target state, but TFS denied to save such a combination stating that it is inconsistent.
Background: we have "In progress" and "In review" task states and it is required that review is done by another developer.
You could use the NOTSAMEAS https://msdn.microsoft.com/en-us/library/ms194953.aspx if you copy the original field value somewhere first so it can be compared with that rule.
I have setup an alert on our TFS server attached to the Work Item Changed event using Alerts Explorer. The only clause I have in the alert has a field of Iteration ID and an operator of Changes. My filter expression is :
"ChangedFields/IntegerFields/Field[ReferenceName='System.IterationId']/OldValue" <> "ChangedFields/IntegerFields/Field[ReferenceName='System.IterationId']/NewValue"
However, when I change the Iteration of a work item I never receive an email. Other alerts based on the Work Item Changed event on the same server are coming through with no problem.
I 'm not sure what "Iteration ID" stands for, but when you change the "Iteration" in your work item, then "Iteration Path" gets surely changed.
So reform your clause for "Iteration Path" instead:
"CoreFields/StringFields/Field[ReferenceName='System.IterationPath']/NewValue" under '\'
This corresponds to a configuration like this:
Once work items in a particular workflow reach a "tested/resolved" end state, I don't want them to be editable. I could enter Field restrictions on the end state for every field that exists, but that's a pain and doesn't easily support the addition of future fields. Is there an easier way?
Thanks!
Alas, I don't think there is an "out of the box" way to do this except for using the "when" clause on each of the fields or adding it to the state transitions to "tested/resolved" (as you have indicated).