This path is not anchored in the source project name

[tzavalunovaG]

Hi,

I was trying to migrate one project from one organization to another and got this error. I was putting exclude on the node level but seems like it did not work.

I see the commit on Mar 9 that seems like could be a fix for my issue. If so, would be it possible to have new release for the tool to try it out?

[06:38:13 DBG] NodeStructureEnricher.GetNewNodeName(OCTO\Dev Enablement - Tech Board, Area)
[06:38:13 DBG] NodeStructureEnricher.GetNewNodeName(blueprints\triage, Area)
[06:38:13 INF] DONE in 00:08:42.0566731
[06:38:13 FTL] Error while running WorkItemMigration
System.InvalidOperationException: This path is not anchored in the source project name: blueprints\triage
   at MigrationTools.Enrichers.TfsNodeStructure.GetNewNodeName(String sourceNodePath, TfsNodeStructureType nodeStructureType) in D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:line 106
   at MigrationTools.Enrichers.TfsNodeStructure.CheckForMissingPaths(List`1 workItems, TfsNodeStructureType nodeType) in D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:line 506
   at MigrationTools.Enrichers.TfsNodeStructure.ValidateTargetNodesExist(List`1 workItems) in D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:line 527
   at VstsSyncMigrator.Engine.WorkItemMigrationContext.InternalExecute() in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 164
   at MigrationTools._EngineV1.Processors.MigrationProcessorBase.Execute() in D:\a\1\s\src\MigrationTools\_EngineV1\Processors\MigrationProcessorBase.cs:line 47\

Regards, Tatyana

[MrHinsh]

Can you plese provide your config?

[marcperez19]

Hi, I'm facing the same problem with a, it seems, deleted project. In the source organization I'm targetting a concrete project, but I don't know why is getting this.

[16:20:17 FTL] Error while running WorkItemMigration System.InvalidOperationException: This path is not anchored in the source project name: fd572af4-c403-482c-aa26-f0ffac0653e5\Modern Workplace Team en MigrationTools.Enrichers.TfsNodeStructure.GetNewNodeName(String sourceNodePath, TfsNodeStructureType nodeStru/ctureType) en D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:línea 106 en MigrationTools.Enrichers.TfsNodeStructure.CheckForMissingPaths(List 1 workItems, TfsNodeStructureType nodeType) en D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:línea 506 en MigrationTools.Enrichers.TfsNodeStructure.ValidateTargetNodesExist(List 1 workItems) en D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:línea 527 en VstsSyncMigrator.Engine.WorkItemMigrationContext.InternalExecute() en D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:línea 164 en MigrationTools._EngineV1.Processors.MigrationProcessorBase.Execute() en D:\a\1\s\src\MigrationTools\_EngineV1\Processors\MigrationProcessorBase.cs:línea 47

My configuration file is like this: { "ChangeSetMappingFile": null, "Source": { "$type": "TfsTeamProjectConfig", "Collection": "https://dev.azure.com/XXXX/", "Project": "Microsoft 365", "ReflectedWorkItemIDFieldName": "Custom.ReflectedItemId", "AllowCrossProjectLinking": false, "AuthenticationMode": "AccessToken", "PersonalAccessToken": "abcd", "PersonalAccessTokenVariableName": "", "LanguageMaps": { "AreaPath": "Area", "IterationPath": "Iteration" } }, "Target": { "$type": "TfsTeamProjectConfig", "Collection": "https://dev.azure.com/YYYY/", "Project": "AUSA", "ReflectedWorkItemIDFieldName": "Custom.ReflectedItemId", "AllowCrossProjectLinking": false, "AuthenticationMode": "AccessToken", "PersonalAccessToken": "defg", "PersonalAccessTokenVariableName": "", "LanguageMaps": { "AreaPath": "Area", "IterationPath": "Iteration" } }, "FieldMaps": [], "GitRepoMapping": null, "LogLevel": "Information", "CommonEnrichersConfig": null, "Processors": [ { "$type": "WorkItemMigrationConfig", "Enabled": true, "ReplayRevisions": true, "PrefixProjectToNodes": false, "UpdateCreatedDate": false, "UpdateCreatedBy": false, "WIQLQueryBit": " AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan','Shared Steps','Shared Parameter','Feedback Request')", "WIQLOrderBit": "[System.ChangedDate] desc", "LinkMigration": true, "AttachmentMigration": true, "AttachmentWorkingPath": "c:\temp\WorkItemAttachmentWorkingFolder\", "FixHtmlAttachmentLinks": true, "SkipToFinalRevisedWorkItemType": false, "WorkItemCreateRetryLimit": 5, "FilterWorkItemsThatAlreadyExistInTarget": true, "PauseAfterEachWorkItem": false, "AttachmentMaxSize": 480000000, "AttachRevisionHistory": true, "LinkMigrationSaveEachAsAdded": false, "GenerateMigrationComment": false, "WorkItemIDs": null, "MaxRevisions": 0, "NodeStructureEnricherEnabled": null, "UseCommonNodeStructureEnricherConfig": false, "StopMigrationOnMissingAreaIterationNodes": false, "NodeBasePaths": [], "AreaMaps": {}, "IterationMaps": {}, "MaxGracefulFailures": 0, "SkipRevisionWithInvalidIterationPath": false, "SkipRevisionWithInvalidAreaPath": false } ], "Version": "12.7", "workaroundForQuerySOAPBugEnabled": false, "WorkItemTypeDefinition": { "sourceWorkItemTypeName": "targetWorkItemTypeName" }, "Endpoints": { "InMemoryWorkItemEndpoints": [ { "Name": "Source", "EndpointEnrichers": null }, { "Name": "Target", "EndpointEnrichers": null } ] } }

[MrHinsh]

This is an error that we are struggling with a good logical and repeatable solution to.

It is caused by a work item being moved to the Source project from another source collection/organisation project. The offending area/iteration path includes the old project name and this of course does not exist in the new location.

How would you like to handle this?

[marcperez19]

Is there a way to know which is the work item that causes this?

Is it possible to ignore this information from the task so that it does not take it into account for the migration?

[MrHinsh]

This is most often because a Work Item has been moved from one project to another. Thus the old iterations are not valid.

[MrHinsh]

Is there a way to know which is the work item that causes this?

Is it possible to ignore this information from the task so that it does not take it into account for the migration?

The work item that caused it is listed right before the exception. Its was the last one that was "unable to save"

[LokeshManjegowda]

I am facing an issue when an area path and iteration path have been changed in a work item and unable to create revision or history in the target. I had to set 'ReplayRevisions' to false to proceed further to unblock work item creation in the target. I have mapped as shown below in the configuration file but it is not working as expected. It does not consider this mapping while adding revision to the target. Any help is greatly appreciated?

Pull request https://github.com/nkdAgility/azure-devops-migration-tools/pull/1440 did not help in my case.

"CommonEnrichersConfig": [ { "$type": "TfsNodeStructureOptions", "Enabled": true, "PrefixProjectToNodes": false, "NodeBasePaths": [], "IterationMaps": { "SourceProject\DevCon UAT Round 2": "Dynamics Development Controls\DevCon UAT Round 2"

}, "AreaMaps": { "TargetProject\High Connect for DevCon": "Dynamics Development Controls\High Connect for DevCon" } } ],

Here is the error for the replaying revisions.

[jjolidon]

So while replaying revisions, all changes will be applied to the work item one by one. This means that all possible values for area and iteration paths for all versions of the work items must exist in the target project (or be remapped).

So if you have work items under MappedPath that previously were under UnmappedPath and you replay revisions, the UnmappedPath will not be found in the target project and the copy will fail.

Another possibility is that the path for one of these items was not selected for migration in the paths migration settings.

One option I see is to have a "catch-all" remapping rule that maps to an existing CatchAll path in the target project. You would have to make sure the rule does not overlap with other rules, though, as the rules are not applied in sequence if I remember well.

If someone volunteers, I see a couple of improvements that could solve these issues entirely:

• Support catch-all rules for the maps, or apply the rules in sequence so that we have a guaranteed fall-through (then adding the catch-all would be trivial)
• Create area and iteration paths on-demand rather than at the beginning of the migration

[MrHinsh]

This is great @jjolidon.

Some additional things to think about:

• Testing that Area/Iterarions exist take clock cycles. Perhaps load all of them at the start in the target and continuously check against that in memory set.
• adding in demand does not seam to work with the Object Model API as it continues to return a fail even after it's been added without a complete refresh of the API.(restart of app)

The path not anchored issue is bigger as they are area or interaction paths from work items that have been moved between projects and the hole thing is invalid...

There is already a feature that will add any missing area and iteration paths, but that's not always the correct outcome, especially of it's been deleted before.

Right now we check all of the loaded work items area and iteration paths against the current target set at the beginning of the migration and list for you all of the ones that don't exisallows youhe option to add mappings or create what you want. Then restart...

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days