You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/content/docs/setup/reflected-workitem-id/index.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,11 +12,11 @@ discussionId: 2825
12
12
---
13
13
The Azure DevOps migrations Tools has no internal state, and uses a field on the work item to track the migration of work items. This field is always referred to in the docs as `ReflectedWorkItemId` and is used to track the work item in the target. It enables the ability to resume migrations as well as to be able to scope the work items based on a query and have multiple runs overlap.
14
14
15
-
Se below how to add the `ReflectedWorkItemId` to your target project as its different for Azure DevOps, TFS, and if you imported your Collection from TFS to Azure DevOps.
15
+
See below how to add the `ReflectedWorkItemId` to your target project as its different for Azure DevOps, TFS, and if you imported your Collection from TFS to Azure DevOps.
16
16
17
17
## How to use the ReflectedWorkItemId
18
18
19
-
In your configuration file under `MigrationTools:Endpoints` there will be both a `Source` and a `Target` endpoint. On the `Target` endpoint there should be a property called `ReflectedWorkItemID*` (depending on the specific endpoint implmnetation) that will have a property value like `Custom.ReflectedWorkItemId`. This is the field that the tool will use to track the work items in the target.
19
+
In your configuration file under `MigrationTools:Endpoints` there will be both a `Source` and a `Target` endpoint. On the `Target` endpoint there should be a property called `ReflectedWorkItemID*` (depending on the specific endpoint implementation) that will have a property value like `Custom.ReflectedWorkItemId`. This is the field that the tool will use to track the work items in the target.
20
20
21
21
```json
22
22
{
@@ -48,11 +48,11 @@ In your configuration file under `MigrationTools:Endpoints` there will be both a
48
48
}
49
49
```
50
50
51
-
When you create the field you will be able to see the`RefName` (different from the display name) in the field settings. This is the value that you will use in the configuration file. It will always have at least one `.` in the name. On the inherited processes it will be `Custom.ReflectedWorkItemId` (unless you created your process and added the field many moons ago, in which case it will be `processName.ReflectedWorkItemId`). On the XML process it will be whatever you want to call it But I recommend something like `TfsMigrationTool.ReflectedWorkItemId` or just `ReflectedWorkItemId`.
51
+
When you create the field you will be able to see the`RefName` (different from the display name) in the field settings. This is the value that you will use in the configuration file. It will always have at least one `.` in the name. On the inherited processes it will be `Custom.ReflectedWorkItemId` (unless you created your process and added the field many moons ago, in which case it will be `processName.ReflectedWorkItemId`). On the XML process it will be whatever you want to call it, but I recommend something like `TfsMigrationTool.ReflectedWorkItemId` or just `ReflectedWorkItemId`.
52
52
53
53
## Work Items you can't customise!
54
54
55
-
If you need to migrate work items that you cant customise, then you will need to use one of the built in fields and I recommend `Microsoft.VSTS.Build.IntegrationBuild`. This field is only used by builds, and is relatively safe to use.
55
+
If you need to migrate work items that you can't customise, then you will need to use one of the built in fields and I recommend `Microsoft.VSTS.Build.IntegrationBuild`. This field is only used by builds, and is relatively safe to use.
56
56
57
57
This is primarily of concern for [How-to: Migrating Plans and Suits](_howto/migrating-plans-and-suites.md).
58
58
@@ -70,7 +70,7 @@ With the advent of the [data migration tool for Azure DevOps](https://learn.micr
70
70
71
71
If you created the Team Project via the web based Azure DevOps UI. You need to [add a custom field through the VSTS UI](https://blogs.msdn.microsoft.com/visualstudioalm/2015/12/10/adding-a-custom-field-to-a-work-item/) to be able to use the tool.
72
72
73
-
The name you should use for the custom field on a VSTS instance is not `TfsMigrationTool.ReflectedWorkItemId` as .(period) are not valid characters for field name. Instead just use `ReflectedWorkItemId` but note that in the `configuration.json` file the name you need to enter is `NameOfYourCustomisedTemplate.ReflectedWorkItemId`. Where`NameOfYourCustomisedTemplate` is the name of your customised template, any spaces in the name will be replaced by \_ (underscore).
73
+
The name you should use for the custom field on a VSTS instance is not `TfsMigrationTool.ReflectedWorkItemId` as .(period) are not valid characters for field name. Instead just use `ReflectedWorkItemId` but note that in the `configuration.json` file the name you need to enter is `NameOfYourCustomisedTemplate.ReflectedWorkItemId`. Where`NameOfYourCustomisedTemplate` is the name of your customised template, any spaces in the name will be replaced by \_ (underscore).
0 commit comments