For some custom fields if the value was made blank in JIRA then it shows the previous revision in ADO about jira-azuredevops-migrator

[Alexander-Hjelm]

PR merged! Thanks for the nice contribution :)

[Alexander-Hjelm]

Wondering if this is maybe related to the MapTags mapper. I will try to replicate the scenario where the tags are unset.

What type is the field "Resolution Version(s)"? Is it a built-in or custom field?

[Alexander-Hjelm]

Exporting an issue where the tags have been removed works fine:

@shweta22992 Maybe the issue comes from using the MapTags mapper for another field than Labels. Do you have a particular reason for using it for the Resolution Version(s) field?

[shweta22992]

@Alexander-Hjelm it may be taking None as a value, when I check the history I get it like below -

"Resolution Version(s)" is a custom field we are using.
MapTags I am using as we run some custom code on that field and we want that to be delimited by some proper character that can be checked, initially it was coming space separated, so by MapTags it made it semicolon separated

[Alexander-Hjelm]

@shweta22992 Why not just use MapArray instead?

[shweta22992]

I was initially using MapArray but that was giving space delimited which we think may not be a robust option to go with for processing later.
Also I tried removing the MapTags mapper and still it was giving me the issue.

[Alexander-Hjelm]

That shouldn't be possible. The MapArray mapper will take the value, split by comma and delimit the result by semicolon. You can refer to the source code here: https://github.com/solidify/jira-azuredevops-migrator/blob/master/src/WorkItemMigrator/JiraExport/RevisionUtils/FieldMapperUtils.cs#L149

[shweta22992]

@Alexander-Hjelm I will take a look at this and again try to change, but if you can suggest something for the data issue after getting blank, as that is the more problematic thing for us currently

[shweta22992]

@Alexander-Hjelm I have raised a PR for this
shweta22992#1
do let me know if this looks fine or any suggestions you have

[Alexander-Hjelm]

@shweta22992 Ah! That could indeed be an issue. My bad. Thanks for sniffing this one out.

I think a safer way would be to store (value || "") in an interim variable, so that we don't accidentally edit something outside of the current block.

I will create a fix for this asap.

[Alexander-Hjelm]

@shweta22992 Nevermind, upon closer inspection I think your PR looks good enough as it is.

It seems like you have raised a PR to the main line of your own fork. I'm not sure if this was on purpose or not?

If you want credit for you fix, please edit the PR so that it merges into the main repo! Let me know otherwise and I'll apply the fix.

[shweta22992]

@Alexander-Hjelm no that got by mistake I think. was truing to raise to the main repo. I will check where I have to make change for pointing it to main repo

[shweta22992]

#940