\n In order to support existing process templates, we use an inference approach to determine identity fields. We consider a field an identity field if it contains any of the following:\n <\/p>\n
- \n
- \n A valid user rule\n <\/li>\n
- \n A group scoping allowed or prohibited value rule\n <\/li>\n
- \n An individual user allowed or prohibited value rule\n <\/li>\n<\/ol>\n
\n \u00a0\n <\/p>\n
\n For example, the following field definition defines an identity field because of the ValidUser rule:\n <\/p>\n
<FIELD name=\"My Identity\" refname=\"My.Identity\" type=\"String\" syncnamechanges=\"true\" > <br \/> <ALLOWEXISTINGVALUE \/> <br \/> <VALIDUSER \/> <br \/><\/FIELD> <\/code> <\/p>\n\n This one makes use of an Allowed Values rule to specify an identity:\n <\/p>\n
<FIELD name=\"Another Identity\" refname=\"Another.Identity\" type=\"String\" syncnamechanges=\"true\" ><br \/> <ALLOWEDVALUES> <br \/> <LISTITEM value=\"[global]Project Collection Valid Users\" \/> <br \/> <\/ALLOWEDVALUES><br \/> <\/FIELD> <\/code> <\/p>\n\n \u00a0\n <\/p>\n
\n Both of the examples show the\u00a0syncnamechanges\u00a0property set to true. It is important to set this to true for identity fields to ensure they work correctly when a user changes their name. If you have an identity field with this property not set you can change it (as of TFS 2015 Update 1)\u00a0using\u00a0witadmin<\/a>.\n <\/p>\n
\n \u00a0\n <\/p>\n
\n Note:<\/strong>\u00a0Identity fields are scoped to the entire team project collection. If one work item\u00a0type\u00a0indicates that a field is an identity, this field becomes an identity field for all types in the collection.\n <\/p>\n
\n Once the system marks a field as an identity field several changes occur: it gets a new UI control and the REST API and\u00a0ClientOM\u00a0change what values they accept and return.\n <\/p>\n
\n \u00a0\n <\/p>\n
\n Identity Control\n <\/h2>\n
\n All identity fields get a new picker which treats identities as first class values. In the web portal, this picker contains an MRU (most recently used) + the ability to search for all other identities.\n <\/p>\n<\/div>\n
\n \u00a0\n<\/div>\n\n \u00a0![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/01\/8741.idPicker.png\")
<\/a>\n<\/div>\n\n \u00a0\n<\/div>\n\n \u00a0One big change with this picker is that it\u2019s no longer scoped based on rules. The picker will search all valid identities in your collection. If you pick a value that is invalid based on your rules, it will validate and report a field error before you save. Search is not scoped for a few reasons:\n<\/div>\n\n- \n
- \n Consistent with how majority of users are using identities\n <\/li>\n
- \n Improved Performance\n <\/li>\n
- \n Support for Azure Active Directory (AAD)\n <\/li>\n<\/ol>\n
\n \u00a0\n <\/p>\n
\n REST APIs\n <\/h2>\n
\n The data returned and accepted by\u00a0\u00a0WIT REST API\u2019s<\/a>\u00a0for identity fields has changed. Reading a value for an identity now returns a combo-string that contains the user\u2019s display name followed by their unique name in brackets. For example, the following GET response\u00a0CreatedBy\u00a0field contains the value \u201cJamal Hartnett
\n \u00a0\n <\/p>\n
\n
![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/01\/6242.getWorkitems.png\")
<\/a>\n <\/p>\n<\/div>\n\n\n When posting an update to a work item or querying work items, the REST API\u2019s now accept that same combo-string in order to unambiguously refer to an identity.\n <\/p>\n
\n \u00a0\n <\/p>\n
\n Query<\/strong>\n <\/p>\n
\n For query you can post WIQL like the following to find all work items assigned to \u201cJamal Hartnett
\n![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/01\/4405.runWiqlCombo.png\")
<\/a>\n<\/div>\n\n \u00a0\n<\/div>\n\n \u00a0\n<\/div>\n\n\n By passing the combo-string, only the identities assigned to this particular identity are returned. However, if you were to omit the email\/alias portion of the string and just pass the display name, it would still work as expected except if the name was ambiguous. If there were two Jamal Hartnett\u2019s, then the following query would return items from both. This makes sense because we are not uniquely\u00a0identifying\u00a0which one we want:\n <\/p>\n
![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/01\/5076.runWiqlDisplayName.png\")
<\/a>\n <\/p>\n<\/div>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/01\/1207.updateWOrkItem.png\")
<\/a>\n <\/p>\n<\/div>\n