We are an on-premisesTFS site. We implement the WorkItemChangedEvent interface because we synchronize TFS edits with a legacy corporate database. One of the workitems fields, Assigned To, is synchronized with this legacy db. When TFS 2015
was introduced, or thereabout, it started using this type of value for the user's identity:
|Name, Display%GUID| ie |Smith, John%1076f1d4-92b0-4bc9-888c-2867aed99247|
At the same time, TFS started using the following value to indicate "Unassigned" or Null user: |%00000000-0000-0000-0000-000000000000|
We had a few complaints that the Assigned To value was not being passed on to legacy, and in troubleshooting the problem, we saw that sometimes the user's identity comes to us as "|Smith, John%00000000-0000-0000-0000-000000000000|"
Our code was mistakenly looking to see if the ID contained the null guid value, and now we've modified it to see if it is exactly "|%00000000-0000-0000-0000-000000000000|". This solved this problem.
What I would like to know is this: why is the guid sometimes set to this null value? One thing to add is that in the same workitem changed event, that Assigned To and Changed By were both set to "|Smith, John%00000000-0000-0000-0000-000000000000|",
but the System.AuthorizedAs value (Authorized As) was set to |Smith, John%1076f1d4-92b0-4bc9-888c-2867aed99247|
Huh? What gives? What is the guid used for, and why is it sometimes NULL?
Thanks!
J F Conklin