# Initial Symptom and Investigation
- After Applying VS2012 Update1 to our production TFS Server, Standard Users in the Contributors group (and other groups) were then unable to access work items.
However users in the Administrators group were still able to see, access and modify Work Items.
This was the case using both the Visual Studio UI and the Web Interface UI.
# Temporary Fix
To further investigate this problem and provide a temporary fix we modified the Contributors group to have all the same permission settings as the Administrators group.
However this did not resolve the problem which suggests it is not directly a straightforward permissions thing but something under the covers.
Consequently as the Administrators group didn't exhibit the problem we then implemented a temporary fix, that worked, by creating a temporary group to consolidate all the classes of Standard Users into and then added that group as a member of the Administrators group.
This then allowed standard users to see, access and modify the Work Items.
Obviously though, this is not an ideal solution as every user now has the full power of an administrator and can modify the contents of folders that we normally specifically prevent them from editing.
# Further steps taken and pertinent information to try to resolve and analyse the problem further;
- Applied matching vs2012 client Update1 to client machine to match the Update 1 already applied to TFS Server
RESULT! This made no difference and we got the same errors/behaviour signature.
- Difference in Symptom between VS2010 and VS2012
In VS2010 the only symptom was that work items and queries failed to appear in Team Explorer.
In VS2012 We get a visible highlighted error, shown below, under the Team Projects in Team Explorer, as well as no work items or queries available.
ERROR! TF26193: The team project VisiWeb does not exist. Check the team project name and try again.
- All these above errors and investigations were on our production TFS Server which has had some historical issues to do with database integrity and size blow out.
Note that the production database has a history dating back to being created with TFS2005, updated through 2008, 2010 and then recently 2012 when this issue appeared.
So we checked for the issue on our two other TFS Servers; one used for Semi-Production testing and the other used for development.
Both servers had also been upgraded to TFS2012 Update1.
On the SemiProd server a copy of the production server TFS Database was in place.
It exhibited the same failing behaviour - ie Non Administraion group users COULD NOT see Work Items.
On the Dev Server we used a collection that had been created on that server from scratch.
This did not exhibit the problem - ie Non Administration group users COULD see Work Items.
# As well as the above UI observed symptoms we also had an error in our Continuous Integration builds which used a user in the Build Administrators group (ie another non Administrators group)
The following dump indicates which .net method it fails in.
Exception Message: TF201077: The work item type cannot be found. It may have been renamed or destroyed. (type WorkItemTypeDeniedOrNotExistException)
Exception Stack Trace: at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.get_Type()
at Microsoft.TeamFoundation.Build.Workflow.Activities.AssociateWorkItems.UpdateWorkItem.Execute(CodeActivityContext context)
at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
NOTE! The error message we were getting was,
"Exception Message: TF201077: The work item type cannot be found. It may have been renamed or destroyed. "
This was subtly different to the instances of this same error we found in our web search of the issue.
In those examples the Type of work item is reported in the message,
eg "Exception Message: TF201077: The work item type Task cannot be found. It may have been renamed or destroyed. "
In ours the work item type appears to be a blank/nil string, hence the two spaces between "work item type" and "cannot"