Migrating work items after Process Change

[tdebusscher]

While running the migration I get on a bunch of PBI's the error

Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemTypeDeniedOrNotExistException: TF201077: The work item type cannot be found. It may have been renamed or destroyed.

When looking further in the logs, the cause of the failure is

WorkItem has changed type at one of the revisions, from User Story to Product Backlog Item

How can I handle this error?

[FokkoVeegens]

Looking for an answer to the same issue (in my case it's an Issue that has been changed to PBI). I have added a WorkItemTypeDefinition to my config.json, but this doesn't help;

"WorkItemTypeDefinition": {
    "Feature": "Feature",
    "Epic": "Epic",
    "Bug": "Bug",
    "Product Backlog Item": "Product Backlog Item",
    "Issue": "Product Backlog Item",
    "Task": "Task",
    "Impediment": "Impediment",
    "Test Plan": "Test Plan",
    "Test Suite": "Test Suite",
    "Test Case": "Test Case",
    "Shared Steps": "Shared Steps",
    "Shared Parameter": "Shared Parameter",
    "Feedback Request": "Feedback Request",
    "Feedback Response": "Feedback Response",
    "Code Review Request": "Code Review Request",
    "Code Review Response": "Code Review Response"
  }

Apparently there is a setting: SkipToFinalRevisedWorkItemType, specifically for this scenario, but it didn't work in my case. I still got the same TF201077 error messages.

In the end, I skipped the revisions migration by setting ReplayRevisions to false.

[MrHinsh]

What you have above will not work as the left is all the same as the right. The missing work item type from the left is not mapped to an existing one on the right!

"WorkItemTypeDefinition": {
    "User Story": "Product Backlog Item",
  }

Same to same is the default.

[FokkoVeegens]

Thanks for your explanation @MrHinsh, my example was meant for a similar case as the one from the OP, not exactly the same case. In my case, there is one mapping that is not "same to same": I map Issue to Product Backlog Item, as in this case, my customer changed their Process from Basic to Scrum.

[MrHinsh]

SkipToFinalRevisedWorkItemType is supposed to be the resolution, but it looks like its not actually used.

       //If work item hasn't been created yet, create a shell
       if (targetWorkItem == null)
       {
           var finalDestType = revisionsToMigrate.Last().Type;
           var targetType = revisionsToMigrate.First().Type;

           if (targetType != finalDestType)
           {
               TraceWriteLine(LogEventLevel.Information, $"WorkItem has changed type at one of the revisions, from {targetType} to {finalDestType}");
               --> Here we should detect if the work item type for the revision even exists... and if not auto skip to final!
           }

           if (Engine.TypeDefinitionMaps.Items.ContainsKey(targetType))
           {
               targetType = Engine.TypeDefinitionMaps.Items[targetType].Map();
           }
           targetWorkItem = CreateWorkItem_Shell(Engine.Target.WorkItems.Project, sourceWorkItem, targetType);
       }

Looking at the code, it detects enough to write out a message but does not actually do anything with it.

At the "-->" we should detect if the work item type for the revision even exists... and if not auto skip to final! Is that your expectation?

We don't want to always do this as we do have code to switch the type as we go. Your circumstance is a process migration, and that is a different beast.

[MrHinsh]

SkipToFinalRevisedWorkItemType is misnamed and be not been able to descend it's purpose.

Keep it false and the system will change the work item type on the way through at the correct revision.

[srousa]

Thank a lot @MrHinsh ! It helped (at least for some items, trying to figure out why it didn't for others). One more question. Is there a setting to not migrate all prev revisions, but only the last one?

[MrHinsh]

Yes, there is a revision depth setting. If set to 10 it will migrate the first revision, and then only the last 10.

[srousa]

Thank you @MrHinsh ! Ah! Maybe that's why some of our items are not migrated properly for those cases! Is there a default setting for this if it's not explicitly set? I don't see anything about revision depth, unless this is it: "MaxRevisions" (we have it set to 0) If that's not it, can you please share what's it called exactly? Thank you so much for being so helpful!!!

[MrHinsh]

It is MaxRevisions and the default of 0 will migrate all revisisons