This is a complaint i hear often. When someone who has a work item assigned leaves a company or loses security privileges over TFS, the work item can' be updated anymore, because the owner of the work item is no longer a valid user of the project.
If you are willing to change the owner of the work item, that isn't a problem. However if you wish to keep the owner (eg: the work item is closed, you just want to update some fields) you will have problems.
If you change some fields and try to save it, you will get the error TF20015, stating that the 'Assigned To' field contains a value that is not on the supported list.
Why does this happen? If we look at the definition of the assigned to field in MSF Agile process template (any work item type), we typically have this
<FIELD type="String" name="Assigned To" refname="System.AssignedTo">
<VALIDUSER />
</FIELD>
The only restriction that this field has, it that it has to be a valid user.
When we remove the user from the project, we can no longer update the work item (assuming we are not changing the assigned to field) since it violates this rule.
Fortunately the solution is quite easy. All we have to do is add a rule to specify that we will allow invalid values if (and only if) the existing field isn't changed. All we have to do is to use the ALLOWEXISTINGVALUE directive.
So to allow us to change work item items, that have assigned users that are (no longer) valid, we have to customize the process template. We should customize for all work item types and use this definition for the Assigned To field.
<FIELD type="String" name="Assigned To" refname="System.AssignedTo">
<VALIDUSER />
<ALLOWEXISTINGVALUE />
</FIELD>
This will solve the problem. However I prefer to have a more evolved definition for the assigned to field. This definition is too broad, it shows on the assigned to field a list of all valid TFS users (independently of having project access or not).
Quoting from the valid user rule "If you do not define one of the optional attributes, all valid Team Foundation Server users and groups will be able to modify the field."
But i prefer a more restrictive view. Only list users that have access to the project. So when customizing process templates, I typically use this definition for the assigned to field:
<FIELD name="Assigned To" refname="System.AssignedTo" type="String">
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="[Project]\Contributors" />
<LISTITEM value="[Project]\Project Administrators" />
</ALLOWEDVALUES>
<PROHIBITEDVALUES expanditems="true">
<LISTITEM value="tfsservice" />
</PROHIBITEDVALUES>
<ALLOWEXISTINGVALUE />
</FIELD>
This definitions, states that only users who are contributors or project administrator of the project will be listed. (will exclude the tfsservice account from the listing. tfsservice being the account name that runs the service. By default Microsoft recommends tfsservice name, but your installation may vary). I also use the allowexisting value to allow us to edito work items assigned to users who no longer have access to the project.