Field Replacements not working about vsts-work-item-migrator HOT 7 CLOSED

Thanks so much @sferg-msft
Enjoy your holiday.

Meanwhile I've had a play with my TFS server and if I change the method in question to this, it starts working:

        public bool FieldIsWithinType(string sourceFieldName, string sourceWorkItemType)
        {
            ISet<string> fieldsOfKey = this.migrationContext.WorkItemTypes.First(a => a.Key.Equals(sourceWorkItemType, StringComparison.OrdinalIgnoreCase)).Value;
            return (fieldsOfKey.Any(a => a.Equals(sourceFieldName, StringComparison.OrdinalIgnoreCase)) || this.migrationContext.Config.FieldReplacements.Any(b => b.Key.Equals(sourceFieldName, StringComparison.OrdinalIgnoreCase)));
        }

However I then get this error for some reason, which seems to have something to do with applying the tags at the end:

WIT BATCH REQUEST 1:

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

BODY:
[{"op":0,"Path":"/fields/System.Tags","From":null,"Value":"6F078B6C-2A96-453B-A7C3-EACE6E63BB97"}]

RESPONSE CODE:
404

RESPONSE BODY:


WIT BATCH REQUEST 2:

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

BODY:
[{"op":0,"Path":"/fields/System.Tags","From":null,"Value":"6F078B6C-2A96-453B-A7C3-EACE6E63BB97"}]

RESPONSE CODE:
404

RESPONSE BODY:

I guess there is some validation logic some where that I would also need to edit.
This is not massively urgent, so enjoy your holiday and I look forward to hearing back when you had a chance to look.

All the best,
Dan

from vsts-work-item-migrator.

I'm experiencing this Issue as well, any news on getting is fixed?!

from vsts-work-item-migrator.

Hi @francescoPizzolon,
We had a look at this together today, and here is a summary of what we discussed.

We stepped through the code and found that your settings are getting discovered correctly. However, the matching logic does not account for field names that start with different prefixes.

Your source project is in TFS 2017.2, which can use any type of field declaration.

• Scrum.v3.EstimatedEffort
• Custom.Confidence
• TfL.BusinessSummaryInfo
• TfL.ProjectCode

can all occur in the same process definition.

In VSTS the visual process editor gives you a standardised prefix based on the process name. (in your case: ScrumCustomized)

If we look at the code in:
https://github.com/Microsoft/vsts-work-item-migrator/blob/6fe29156d32a338100789b9bef876f4e04a4c822/Common/Migration/Phase1/WitBatchRequestGenerators/BaseWitBatchRequestGenerator.cs

We see at line 307:

public bool FieldIsWithinType(string sourceFieldName, string sourceWorkItemType)
{

ISet<string> fieldsOfKey = this.migrationContext.WorkItemTypes.First(a => a.Key.Equals(sourceWorkItemType, StringComparison.OrdinalIgnoreCase)).Value;

    return fieldsOfKey.Any(a => a.Equals(sourceFieldName, StringComparison.OrdinalIgnoreCase));

}

The logic looks up the destination work item and checks if the source types are there. If they are not, they get thrown out.

@sferg-msft I'll have a dig now, but as this is your class I thought I might as well ask:
If it isn't in the destination, is it being matched and is the matched field the same type?
If we need another REST call here this could be inefficient. If the info is already there, we might as well match here and allow for this to be written across.

Will boot up my 2017.2 machine now and create a repro.

from vsts-work-item-migrator.

Just to clarify as well: If we rename the destination process to Scrum.v3 and create a field "EstimatedEffort" with the same type as in the source, this works like a charm.

from vsts-work-item-migrator.

I’m on vacation, but when I get back I’ll investigate.

from vsts-work-item-migrator.

We have an issue with the reference field names not matching when trying to migrate from a VSTS instance to another VSTS instance. We get these errors:

[Warning   @14.04.39.776] Target: Field LhiScrum.URSReferenceNumber does not exist in Product Backlog Item
[Info   @14.04.39.776] Work item type Product Backlog Item validation completed but has missing fields, please check the log for more details
[Info   @14.04.39.776] Checking metadata for work item type Bug
[Warning   @14.04.39.776] Target: Field LhiScrum.Production does not exist in Bug
[Warning   @14.04.39.776] Target: Field LhiScrum.SDETicketNo does not exist in Bug
[Warning   @14.04.39.776] Target: Field LhiScrum.EnvironmentFoundIn does not exist in Bug
[Info   @14.04.39.776] Work item type Bug validation completed but has missing fields, please check the log for more details
[Info   @14.04.39.777] Checking metadata for work item type Question
[Info   @14.04.39.777] Work item type Question validation completed successfully
[Info   @14.04.39.778] Checking metadata for work item type Task
[Info   @14.04.39.778] Work item type Task validation completed successfully
[Info   @14.04.39.778] Checking metadata for work item type Impediment
[Info   @14.04.39.779] Work item type Impediment validation completed successfully
[Info   @14.04.39.780] Checking metadata for work item type Epic
[Warning   @14.04.39.780] Target: Field LhiScrum.Stakeholder does not exist in Epic
[Warning   @14.04.39.780] Target: Field LhiScrum.ProjectManager does not exist in Epic
[Warning   @14.04.39.780] Target: Field LhiScrum.TechnicalLead does not exist in Epic
[Warning   @14.04.39.780] Target: Field LhiScrum.RequirementsOwner does not exist in Epic
[Info   @14.04.39.780] Work item type Epic validation completed but has missing fields, please check the log for more details

This is happening because our new VSTS instance allows me to create the LhiScrum process and all these associated fields but has them all as a reference name with a prefix of "Custom" instead of "LhiScrum" and therefore does not find the matching fields.

It doesn't matter if I rename the inherited target process template to "LhiScumX" and then back to "LhiScrum" or delete it and recreate it but it always starts with the "Custom" reference field prefix. Since thesew are both VSTS instances i cannot use the WIT Admin tool to change anything directly so I cannot migrate any of the custom fields.

Any way to relatively easily work around this so I can actually utilize the tool effectively for my migration?

P.S. The "Custom" prefix may be related to that at first cut we had created on the target system a "LhiScrum" process template but too many misconfigurations were done during its creation that is was deleted and started over from scratch thinking that would be easier...

from vsts-work-item-migrator.

I've hit this same problem.

from vsts-work-item-migrator.