Click here to Skip to main content
15,881,757 members
Articles / DevOps / TFS

TF237165: Team Foundation could not update the work item because…

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
25 Jun 2013CPOL2 min read 20.2K   3
Workaround for error message TF237165 from TFS

Full Error Message

TF237165: Team Foundation could not update the work item because of a validation error on the server. This may happen because the work item type has been modified or destroyed, or you do not have permission to update the work item.

History

A while back, I received the TF237165 error message from TFS when reordering work items on the backlog. I did what most people would do and went to Google for while, none of the posts I found seemed to help (I thought). I spent a while trying to figure out what’s going on by trying all kinds of things from profiling SQL, enabling Trace on the web access site and trying to get some useful information using fiddler.

Workaround

Not really a good workaround but for the work items that were breaking I was able to open the items and manually change the backlog priority to a number in between the backlog priority of the 2 work items I wanted to move the broken work item between. This was fine for a while because it wasn’t happening that often. Recently though, opening some work items and changing any information on them resulted in the same error message above and over the last 2 or so weeks started showing up more and more.

Problem

I tried all the previous methods of finding the problem and came up dry again. I went back to Google. I ended up finding a couple of posts on pages (not marked as answer) saying that it could possibly be the rules on the WIT definition that is causing this error.

Solution

Note: It is advised not to experiment with finding the solution directly on a production system.

To easily see if this was the issue for me, I removed all FIELDS nodes from under the STATE nodes and from under the TRANSITION nodes. Importing the definition into TFS and “magically” all my problems went away. While not quite, all of the rules were required for some or other reason in the processes that were defined. I then reverted all my changes and now focused only on the rules themselves with the FIELDS, I removed a couple of fields that I thought could specifically be causing the issues and imported again, again the problem was fixed and now I had a smaller problem area.

The fields that I removed were the Microsoft.VSTS.Common.ActivatedBy and Microsoft.VSTS.Common.ActivatedDate but only in the STATES node.

XML
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
<SERVERDEFAULT from="currentuser" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<SERVERDEFAULT from="clock" />
</FIELD>

Reverted changes again, now having only these two fields to work with now I ended up next changing the SERVERDEFAULT rule to COPY and importing again. This still worked and I’m assuming is the solution for the issue.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Architect SSW
South Africa South Africa

Comments and Discussions

 
NewsAnother 'Same Error Different Fix' - Profile Display Name Change, ... Pin
ergohack23-Mar-17 13:07
ergohack23-Mar-17 13:07 
QuestionSame error, different fix Pin
Member 1021837925-Oct-13 7:39
professionalMember 1021837925-Oct-13 7:39 
AnswerRe: Same error, different fix Pin
Gordon Beeming30-Oct-13 8:18
professionalGordon Beeming30-Oct-13 8:18 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.