Custom Fields in Work Item Alerts
I created an alert on work items that are assigned to me. But now, I want to shrink the alert to work items with a specific string value in a certain field.
For fields like "Title" I can select "=" or "<>" in the clause.
For other (self defined) string fields, I can only choose between "Changes", "Changes From", "Changes To".
It would be nice to enable the evaluation of custom fields with the "=" selector etc.
This functionality will be part of Sprint 122’s Update. You can read all about it in our release notes (https://www.visualstudio.com/en-us/articles/news/2017/aug-28-team-services#custom-fields-and-tags-in-notifications).
As noted in the article, this feature will be rolling out over the next three weeks to all accounts.
Jose Rady Allende
Program Manager | VSTS
Marius Koch commented
Are there any updates about the availability for on premise TFS?
Robert Koharchik commented
Has this simple change request from 2011 still not been implemented yet? I still do not have the option for Environment = Production... I don't care about the lower environments, and this seems like something basic for people to be able to do their jobs effectively. Please advise.
So what about the TFS On Premise versions ? Im on 2017 Update 2 and dont have this functionality...
What does sprint 122 mean? can this work with TFS 2013 update 4 and VS 2013 update 4?
Asfaw Ayele commented
Will this feature be released for TFS 2017 or 2018?
Nagsen Meshram commented
At this time, because of this limitation, TFS alert will not be sent if we have to match a partial word for that custom field. It has to be an exact match.
Nagsen Meshram commented
TFS Project Alert should have all list of operators available similar to TFS Query.
For custom field, the only three operators available are "Changes", "Changes To" and "Changes From".
It should have all options such as "Contains" etc. Please see attached images.
Alan Thompson commented
Simply need to let the person for whom a bug was submitted know that its been closed which seems a fairly reasonable thing to do.
Ann Myers commented
My simple need is...
State changes to Coded (Core Field)
AND QA Engineer = Me (Non Core Field)
send an alert to my email.
I hate to pull the competitor card, but this is something Jira can do on just about any field in 2 minutes.
Currently the best I can do is set it so that EVERY work item that goes to "Coded" will send me an email alert, this just spams my inbox and isn't useful.
Please up this in priority!
Build Alerts 'Definition Name' only supports '=' and '<>' operators... This is weak. It's a string and would be easy to implement 'Contains' or at least 'Starts With'. This is necessary for companies/organizations that use the TFS build system. For example our BI team has 50+ TFS build workflows that turn different build definitions on. If I want to be alerted for any point in failure, I need to add 50 OR clauses to the alerts interface. Weak sauce!
Matt Hartzell commented
What. In. The. World. Is this a joke? The equality operator is not supported for custom fields? Shame on me for assuming such a basic, trivial piece of functionality was implemented in TFS.
This is absurd.
Nalle Jacobsson commented
Any update on this? We need to email alerts to a user referenced in a custom field
Thomas Beer commented
Just created a Custom Field i wanted to check for in the alerts!
What a bummer. pls MS give me a late Christmas Present.
... it took 3+ years to get planned? This is a core feature in many of your competitor's products.
This is a MUST HAVE, it is ridiculous that it is still not implemented after several years.
An end user is recorded in "Requested By" field - we want to be able to email alerts to the Requester whenever "their" item is updated
Any Update? This is a base request in my mind. We have the same need to pick what our "Core" fields would be so that we have the ability to get emails based on changes on fields we deem necessary
Roman Kotovich commented
Our use case: the task goes through "in progress" -> "in review" -> "done" states. It obviously has to be reviewed not by the same person who preformed (implemented) the task. Thus we have the "Last Assignee" filed to first check that the assignee changed between the "in progress" and "in review" state. Second we planned to use this field to notify this "last assignee" that the task passed the review, just to find out that due to someones design decision we cannot compare those non-core fields.
Jonas Whidden commented
Would also love having this functionality. Specifically, we want the developer who resolved the bug to get an email alert when the bug is closed, through filter:
Resolved By = [Me]
Work Item Type = Bug
State <changes to> Closed
News on this update?