Custom IssueTypes on both ends fails to map

[BenOberholzer]

In JIRA our team had created a 'Technical Debt' issuetype. We similarly created a 'Technical Debt' issuetype in ADO. I mapped the objects like I mapped any other object and ran the export. In the individual export items, none of the standard fields (title, description, etc.) were created in the resulting JSON files for those issues. Epics were created, bugs were created, etc. I tried all sorts of variations of the issuetype name to no avail. The only way I could work around it was to export those items to Bugs and then convert them after importing them to ADO.

Is this a limitation of custom to custom objects or possibly just a failure to look it up correctly? I will try to review the code and see if I can find anything but I thought I'd ask first.

[MOlausson]

Hi @BenOberholzer I would expect this to work. Let's work to track this down. Can you share your config + export log file with me?

[BenOberholzer]

No problem. I have attached both here.
jira-export-log-190530-095606.txt
config-swat.txt

Apparently I can't post a json file so the config file is just changed to a .txt extension.

[MOlausson]

Thanks. Realized I would like to look at the import log as well. But the config looks fine at a first look.

[BenOberholzer]

wi-import-log-190530-113754.txt
Here's the import log.

[MOlausson]

@BenOberholzer did you get this resolved? I checked the logs and don't see the issue, perhaps these were for the files you have manually corrected?

[BenOberholzer]

@MOlausson I actually don't recall seeing errors during the import. The items were created but most of the details (title, description, etc.) were missing. It's like it couldn't map the fields on the import. But then again the exported items from JIRA didn't have those details either. I personally think the problem is on the export side, not the import.

EDIT: Just to clarify, I worked around this by exporting them to a 'bug' type and importing them, then converting them to the custom 'technical debt' item once they were in Azure Devops.

[cia0mari]

@MOlausson I'm having same problem: I'm trying to export Bugs from Jira and importing them as Issues in DevOps but it doesn't set any field. If I import them as Bugs in DevOps it works better.
But still mapping of Jira Status and Priority values to DevOps ones doesn't seem to work; i.e. whatever Jira Status is always mapped to "To Do" DevOps State.
I suppose I'm doing something wrong, so any hint will be appreciated.
I attach my config files for reference.
config-scrum.json.txt
wi-import-log-190610-173851.txt
jira-export-log-190610-173556.txt
Thanks!

[Nick-Sohacki]

I have the same problem too.

[XVII]

+1

[RubenOuwerkerk]

+1

[Jnaneshnayak]

+1

[quadmig]

+1
It does not give an error but it mostly doesn't load (see attachment0.
The exact same item and config imports correctly if the WIT is something else like product backlog item.

[jonada]

I have the same problem. No error or warning, but in the exported .json files several system fields were missing (not exported).

My workaround:

• Instead of exporting from Jira Task to DevOps Task, I configured it to export from Jira Task to DevOps Issue.
• After export, replaced “Task” for “Issue” at the beginning of all .json-files, for those work items that should be Issue instead of Task (since I exported several different types, not all files was to be replaced).

[XVII]

I tried using Issue instead of a custom work item type, but it still didn't export correctly. As soon as it's a custom type on either side, it seems to fail.

[kenjdavidson]

I ran into this issue as well, attempting to convert Jira BUG to DevOps ISSUE and found that the main problem stems from the WorkItemType (enum I guess) only containing a limited number of options, instead of actually being built from the configuration TypeMap.

JiraExport.JiraMapper line 377 - The mappingPerWiType is being built statically with no reference to Issue, therefore if Bug is Mapped to issue, it's not finding a resulting field map and therefore not doing any conversion.

var mappingPerWiType = new Dictionary<string, FieldMapping<JiraRevision>>
    {
        { WorkItemType.Bug, MergeMapping(commonFields, bugFields) },
        { WorkItemType.ProductBacklogItem, MergeMapping(commonFields, pbiFields) },
        { WorkItemType.Task, MergeMapping(commonFields, taskFields) },
        { WorkItemType.Feature, MergeMapping(commonFields, featureFields) },
        { WorkItemType.Epic, MergeMapping(commonFields, epicFields) },
        { WorkItemType.Requirement, MergeMapping(commonFields, requirementFields) },
        { WorkItemType.UserStory, MergeMapping(commonFields, userStoryFields) }
    };

Line 234 is failing:

if (type != null && **_fieldMappingsPerType.TryGetValue(type, out var mapping)**)

Working under the assumption that we only care about Targets, which in my mind is a valid assumption since we're going to DevOps types. I've made the following change to the InitializeFieldMappings method:

• create only those FieldMappings for Target types
• place FieldMappings into either Common or the appropriately named key
• For each TargetType merge field mappings with commonFields.

My C# is pretty terrible but I can submit a PR if you see fit. With my change I'm getting decent conversions from:

Bugs to issues.
Improvements to improvements.

Those are the only two custom mappings we have.

[MOlausson]

@kenjdavidson thanks for your feedback. Happy to review your code if you want to submit a PR.

[kmuthukumar-rp]

@MOlausson Any update on this issue. I am exporting Spike and Defect from Jira and mapping to same on ADO side. But the jira export json files does not have any fields or values in it and hence they are empty when imported into ADO. Doing the workaround that @jonada mentioned will be too much as there are at least 500 jira spikes and defects exported. I have the latest release of the tool. Is there any other workaround or fix for it now or when can we expect it. Appreciate it a lot. Thank you.

[MOlausson]

Fixed from v.2.2.88