This use case is something we noticed when extracting data from Jira for reporting in Tableau. The key concept is a Sub-task-which-was-formerly-a-Task.
The following tools are in play:
If an issue and its parents follow the life-cycle described below, a sub-task will have an old, stale Epic Link in the data pulled from Jira. I'll refer to the specific Jira keys, so both the writer (me) and the reader can keep things straight (hopefully, it is a bit complicated).
This seems to have risen from our introduction of Sub-tasks and subsequent organizing of Epics and Tasks and Stories. The example is one where an Epic becomes a Story and its Tasks/Stories become Sub-tasks. A Jira bug seems to have been lying in the wait.
**Note: a newly created sub-task will NOT have an Epic Link – this is important to know about Jira. A brand new Sub-task just inherits the Epic from its parent (e.g. Story) and Jira manages issues in this way. This is well documented - makes sense to me and is fine (it is frustrating to some).
A question I had is if the extraction performed by the AIO Tableau Connector for Jira Cloud is to blame? I don't think so because the data in Tableau could not possibly just randomly pick the Sub-task's former Epic among other choices. To check that it might be due to stale data, I recreated the scenario with another set of issue and THEN performed the extraction - the same bug was seen again with the wrong Epic Link. The connector could not have possibly guessed the wrong Epic, which the Sub-task happened to be formerly related to.
I think this is a bug for Jira to fix. It is NOT an issue when simply using Jira Cloud. For example, when viewing the parent and Sub-task in Jira all seems well. And performing an export to CSV does not show the issue either. If the Epic Link is still stored against the Sub-task-which-was-formerly-a-Task, Jira does not show it and must kind of ignore it. Jira probably always relies on the Epic Link of the Sub-task's parent and not any Epic Link that may still be stored with the Sub-task-which-was-formerly-a-Task. So the Epic Link of the Sub-task-which-was-formerly-a-Task must be ignored, except when another system extracts data.
I do think we'll have a work-around, but it will be more complicated for us. We'll create several data sources so Sub-tasks can be related to their parent Story via a left join (the parent's Epic Link is okay and is updated as it moves from one Epic to another).
Please look into this issue, Atlassian, and confirm if the analysis is correct. If so, please resolve.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events