nkdAgility / azure-devops-migration-tools

Azure DevOps Migration Tools allow you to migrate Teams, Backlogs, Tasks, Test Cases, and Plans & Suits from one Project to another in Azure DevOps / TFS both within the same Organisation, and between Organisations.
https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration
MIT License
488 stars 325 forks source link

Work Items that have changed Work Item Type not getting migrated. #1581

Closed rmwilkins closed 9 months ago

rmwilkins commented 1 year ago

Discussed in https://github.com/nkdAgility/azure-devops-migration-tools/discussions/1573

Originally posted by **rmwilkins** June 23, 2023 I have a pattern whereby if a work item has had a change in type (e.g. frm a Bug to a User Story) the work item does not get migrated. I'm on v13.07. Any ideas. I predict this is an issue.
MrHinsh commented 1 year ago

This sounds like an issue to me...

RehabAbotalep commented 1 year ago

@rmwilkins I had a similar issue and did some investigation. It seems that the migration tool migrates work items to their original type before changing if the SkipToFinalRevisedWorkItemType key is set to false. However, if the key is true, it migrates the work items to the new changed type.

This is an example of a work item that was changed from a User Story to an Epic:

source-item

  1. SkipToFinalRevisedWorkItemType is set to false, and the work item is migrated as a User Story.

migrated-to-the-final-revision-false

  1. SkipToFinalRevisedWorkItemType is set to true, and the work item migrated as an Epic

migrated-to-the-final-revision-true

So maybe this key is set to false, and the work items migrated successfully but to another type (their original type before changing).

rmwilkins commented 1 year ago

@RehabAbotalep - Already tried that and it does not bring back the desired results. It does not bring back all history etc. I think @MrHinsh already acknowledged as an issue.

MrHinsh commented 11 months ago

Are you using Prompt or PAT?

I think this only works if you use PAT!

RehabAbotalep commented 11 months ago

Are you using Prompt or PAT?

I think this only works if you use PAT!

I was using PAT.

MrHinsh commented 11 months ago

You might need to debug in Visual Studio and see why its not doing it thing.

Its supposed to replace the Work Item Type in the revisions with whatever the latest revision is all the way down.

MSFTkyweis commented 11 months ago

I'm seeing the same behavior in my testing. I'm using "SkipToFinalRevisedWorkItemType: true" to try and avoid the type change, but I'm limited to Prompt authentication (cannot get full access PATs) so I'm wondering if that's part of the issue.

@MrHinsh Am I out of luck on migrating type-changed WIs if I can't get a Full Access PAT?

MrHinsh commented 11 months ago

There is a fix in the system that's supposed to fast forward to the latest wit.

I've had a few reports that it's not working so it looks like it needs some work.

MSFTkyweis commented 11 months ago

Thanks for the quick update. I'll keep an eye on these threads.

MrHinsh commented 11 months ago

Ive checked the code and the simple work around is as @RehabAbotalep described:

SkipToFinalRevisedWorkItemType: true

This will create the work item in its final type state and will work both for PAT and Promopt.

var skipToFinalRevisedWorkItemType = _config.SkipToFinalRevisedWorkItemType;
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}");
}

if (skipToFinalRevisedWorkItemType && Engine.TypeDefinitionMaps.Items.ContainsKey(finalDestType))
{
    finalDestType = Engine.TypeDefinitionMaps.Items[finalDestType].Map();
}

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

Regardless of the setting, you should see "WorkItem has changed type at one of the revisions, from " in the log!

I would assume that if you don't have this set it will, as @RehabAbotalep shows in her screenshots, use the old type.

MSFTkyweis commented 11 months ago

@MrHinsh I deleted the troublesome WIs and re-ran the migration with SkipToFinalRevisedWorkItemType but I'm still getting a failure, so there may be a different issue in my environment. The logs show a save failure with the stack trace error below..

[10:03:23 INF] [ Issue][Complete: 6/6][sid: 15248|Rev: 15][tid: null | System.IterationPath (Iteration Path) | [10:03:23 INF] =============================================================== [10:03:23 INF] [ Issue][Complete: 6/6][sid: 15248|Rev: 15][tid: null | WorkItem has changed type at one of the revisions, from Task to Issue [10:03:23 INF] [ Issue][Complete: 6/6][sid: 15248|Rev: 15][tid: null | Processing Revision [1] [10:03:23 INF] [ Issue][Complete: 6/6][sid: 15248|Rev: 15][tid: null | ...FAILED to Save

[10:03:23 ERR] System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.Services.WebApi.VssServiceResponseException: Page not found. at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d53.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d51.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d47`1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d281.MoveNext() --- End of inner exception stack trace --- at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List1 revisionsToMigrate, WorkItemData sourceWorkItem, WorkItemData targetWorkItem) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 628 ---> (Inner Exception #0) Microsoft.VisualStudio.Services.WebApi.VssServiceResponseException: Page not found. at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<HandleResponseAsync>d__53.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__51.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__471.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d__28`1.MoveNext()<---

As a workaround, just to get the items created, I can set ReplayRevisions to false but obviously I won't have the history attached.

TDouch commented 10 months ago

I am also having trouble with migrating items that have changed type. I have tried updating to the latest version 14.0 as I was having the problem on 13.0. I have tried with SkipToFinalRevisedWorkItemType set to true and false but am receiving the same error as MSFTkyweis posted above.

I am bieng left with a work item created but without an name or any details attatched.

If I run the migration a second time and it does not prompt for access, I assume it has cached it, the I get the following error but again only on items when it is trying to migrate work items that have changed type.

I have checked and im pretty sure I have full access on the source and the target. So I dont know if this error might be a red herring or not.

System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: VS30063: You are not authorized to access https://dev.azure.com. at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.d17.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.d9.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d51.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d471.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__281.MoveNext() --- End of inner exception stack trace --- at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List1 revisionsToMigrate, WorkItemData sourceWorkItem, WorkItemData targetWorkItem) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 631 ---> (Inner Exception #0) Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: VS30063: You are not authorized to access https://dev.azure.com. at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.d17.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.d9.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d51.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d471.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__281.MoveNext()<---

MrHinsh commented 10 months ago

See: https://github.com/nkdAgility/azure-devops-migration-tools/discussions/1693