Work Items not visible to Non administrators group users after TFS2012 Update1 applied - by Peter R Smith

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 780755 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 3/5/2013 9:45:08 PM
Access Restriction Public


# 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"

Sign in to post a comment.
Posted by Microsoft on 3/7/2013 at 7:04 AM
Hi Peter,

We are sorry for the inconvenience this is causing your team. The issue you are facing was due to an edge case bug in the first Quarterly Update. We have since then provided a patch that fixes this issue. Can you please call/or open a ticket with support and have them give you that patch? Have them contact me (alias: mariorod) if they need any additional information.

Again our apologies.

-- mario
Posted by Microsoft on 3/6/2013 at 3:25 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 3/5/2013 at 9:50 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(