solidify / jira-azuredevops-migrator

Tool to migrate work items from Atlassian Jira to Microsoft Azure DevOps/VSTS/TFS.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wrong Sprint Information Exporting

TKallem opened this issue · comments

Describe the problem

When I am exporting an issue and if it has been in multiple sprints, the export process is exporting incorrect sprint information. It seems to export last string after the last comma for Sprint information.

Expected Sprint Information: Sprint 12 2024 (1006 - 2106)
Exported Sprint Information: 2023-2024

To Reproduce

Steps to reproduce the behavior:

  1. Create an issue in Jira
  2. Add the issue to Sprint 1, 2024 (0101 - 0112)
  3. Update sprint to Sprint 5, 2024 (0301 - 0312)
  4. Update sprint to Sprint 12, 2024 (0610 - 0621)

Tool version

  • jira-azuredevops-migrator-3.0.422

Attachments

Please attach the following files:

Look for DSPUBI-1987 issue in this log file jira-export-log-240611-162928.txt
config-agile.json

Screenshots
AzureDevOps
Jira

This sounds like a tricky one!

To start with, I think that this is the intended functionality of the MapSprint mapper. The IterationPath field in ADO can only hold one value at a time. One alternative would be to keep the simply migrate the value of the Sprint field as-is to a custom text field in ADO if you want to preserve all sprint names.

Otherwise, can you please elaborate what you think should be the expected behavior?

Hi @Alexander-Hjelm ,

I think it might be an issue in Jira, as you can see in the activity history, the sprint names are ordered by alphabetical and current sprint value is in the middle. So it looks like the tool is taking the last value which is incorrect in this scenario.

I don't think there is a way to determine the current (active) sprint just from looking at the card in jira or the Rest API? Correct me if I am wrong!

Also, is there a possibility that an issue could be part of several active sprints?

Hi @Alexander-Hjelm,

Looks like it is possible to get the active sprint information from API. Please see below screenshot for reference.

Yes there are quite few issues were in multiple sprints but there is only one active sprint at any given time. It seems in some instances we haven't followed the process to move issues to new sprint when we are completing one.

image

Ok, interesting! I can confirm that the tool does not distinguish between active and closed sprints today.

Still, what would be the expected behavior if there are multiple active sprints? If this is even a possible scenario?

This issue is stale because it has been open for 25 days with no activity.

This issue was closed because it has been inactive for 5 days since being marked as stale.