[Bug]: PopulateWorkItem:FieldUpdate should not log for Missing field if the field is marked as ignored in the TfsWorkItemTypeValidatorTool.ExcludeSourceFields part

[sbouchexbellomie-Philips]

Version

• I confirm that I am using the latest version

Source Version

Azure DevOps Server 2019

Target Version

Azure DevOps Service

Relevant configuration

[...]
"ExcludeSourceFields": { "Epic": [ "aaa.AreaPathString" ] }
[...]

Relevant log output

[10:37:33 WRN] [16.3.2-Local.5] PopulateWorkItem:FieldUpdate: Missing field in target workitem, Source WorkItemId: 194556, Field: aaa.AreaPathString, Value: CapsuleTech\DeCo\DeCo

What happened?

While doing the migration, the log is polluted by entries about missing fields which are ignored.

Debug in Visual Studio

• Visual Studio Debug

[satano]

@sbouchexbellomie-Philips Please "Relevant configuration" does not mean just the single line, even if it is the correct line. Include at least full configuration of the tool it belongs to.

@MrHinsh What do you think? We colud check validator for excluded fields and not output warnings in this case. I can prepare PR. I have just one question – if the validator tool is disabled, should this warning be logged, or still skipped?

[sbouchexbellomie-Philips]

@satano, here is a sanitzed configuration:

source = aaa
dest = xxx

configuration-debug.json

[MrHinsh]

@MrHinsh What do you think? We colud check validator for excluded fields and not output warnings in this case. I can prepare PR. I have just one question – if the validator tool is disabled, should this warning be logged, or still skipped?

I think we need to be careful not to break the architecture and the single responsibility. But it also sounds reasonable.

[satano]

Well single responsibility is not bad point. And when writing this comment, it came to my mind, that we cannot do this. Because ExcludeSourceFields is really only for work item type validator (TfsWorkItemTypeValidatorTool) and this list should not be used automatically elsewhere to make decisions. Because there are (at least) two reasons I do not want to validate some field:

1. I really do not care about the field, it does not exist in target and I will not migrate it. In this case, it would be good to not output warning about missing field in target, because the field is not migrated.
2. I DO care about the field and I want it to migrate. But it is not possible to validate it this static way, because its value will be computed dynamically during migration. For example using MultiValueConditionalMap, FieldMergeMap, or something like that.

I understand, that this warning is annoyng, but if we want to get rid of it, someone need to come up with some new way how to configure fields from point 1.