Work Item Creation fails with 400 response code: "VS403426: IdentityRef type is not accepted for this request."

[dwpeterson]

When I tried this code a month ago for a VSTS to VSTS WIT migration everything worked great. When I went to try it again this week using the same configuration I get a failure with a 400 response back for all attempts to create any type of WIT. Did something change with the VSTS API that has broken this project? Here is an example request url and response (the body contains the WIT field data as I'd expect and have omitted for privacy).

METHOD: PATCH
URI: /MigrationTest1/_apis/wit/workItems/$Epic?bypassRules=True&suppressNotifications=True&api-version=4.0

RESPONSE CODE:
400

RESPONSE BODY:
{"count":1,"value":{"Message":"VS403426: IdentityRef type is not accepted for this request."}}

This happens for every WIT that is in my source query (all different types, Epics, Features, Stories, Tasks, etc). I also tried creating a new VSTS project for a destination just to see if I needed a clean slate, but it made no difference. Anyone know what's going on here? Does this program still work for anyone else?

[Paulohcsantos]

@dwpeterson, I changed the parameter "api-version" to version 5.0-preview, and it worked.
Check out!

[dwpeterson]

No dice.. it still fails.

METHOD: PATCH
URI: /MyFirstProject/_apis/wit/workItems/$Epic?bypassRules=True&suppressNotifications=True&api-version=5.0-preview

RESPONSE CODE:
400

RESPONSE BODY:
{"count":1,"value":{"Message":"VS403426: IdentityRef type is not accepted for this request."}}

[Paulohcsantos]

OK, try replacing the bypassRules parameter to false.

[dwpeterson]

That partially worked.. it allowed 75 of my 361 items to be successful. But the ones its rejecting are due to the state rules such as not allowing creation of a new WIT to be assigned a Closed status. This is of course a problem since I'm migrating an existing in-progress project and we'd like to keep those older WIT as they are linked to on-going work. There are some other rules variations that failed as well: Activated By can't be empty, reason value isn't valid (since you can't set a certain type of reason on a new WIT but the WIT it's trying to migrate is in a not-new state), etc.

Here's one that failed:
METHOD: PATCH
URI: /MyFirstProject/_apis/wit/workItems/$User Story?bypassRules=False&suppressNotifications=True&api-version=5.0-preview

RESPONSE CODE:
400

RESPONSE BODY:
{"fieldReferenceName":null,"fieldStatusFlags":"none","errorMessage":"The field 'State' contains the value 'Closed' that is not in the list of supported values","fieldStatusCode":0,"ruleValidationErrors":[{"fieldReferenceName":"System.State","fieldStatusFlags":"required, hasValues, limitedToValues, invalidListValue","errorMessage":"The field 'State' contains the value 'Closed' that is not in the list of supported values","fieldStatusCode":4194317,"ruleValidationErrors":null}]}

[Paulohcsantos]

I also went through this situation. I solved by changing the status of the tasks to New and setting the Reason field to new too!

[dwpeterson]

That kind of negates the advantage of migrating automatically. I'd then lose the current real status and reason of those items and have to somehow reset them.

[obvioussean]

@dwpeterson This should be resolved, I downgraded the nuget package for the VSTS libraries.