Sub-task, if it began as a parent task, can have wrong Epic Link when extracting data from Jira Edited

[Mike Larsen (AgC)]

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:

• Jira Cloud (not server)
• AIO Tableau Connector for Jira Cloud (installed app which extracts data from Jira and pushes data out via a "Web Data Connector" url)
• Tableau, both Desktop and Online (not server)

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.

1. LDBAPP-237 began as a Task (parent) and it was associated (linked as a child) with LDBAPP-257, which at the time was an Epic
2. LDBAPP-237 dropped from Task to Sub-task and LDBAPP-257 dropped from Epic to Story.
3. At that point, the Epic Link value of LDBAPP-237 is fixed and apparently stored in the Jira database.**
4. Subsequently, the parent Story LDBAPP-257 was moved from its original Epic, LDPAPP-409, to Epic LDBAPP-573. But the Epic Link of the Sub-task LDBAPP-237 was set and did not get updated. (This is the Jira bug, I think)
5. So from that point forward, Sub-task LDBAPP-237 has an Epic Link which is stale and might not be easily changed. The data extraction is given the wrong Epic for the Sub-task.

**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. 

Thanks!

Mike

[Nic Brough _Adaptavist_]

>But the Epic Link of the Sub-task LDBAPP-237 was set

I think you are right here.  Sub-tasks should not have data for the Epic Link because they should be deriving it from their parent.  By converting from task to sub-task, you've ended up with the data populated as a hangover. 

There's several possible bugs here, although fixing any one of them would sort it

• The convert to sub-task is not clearing the epic link field in the back ground
• The code that is getting the epic link out is not taking the fact that it's a sub-task into account and reading it despite it not supposed to be doing it
• The epic link field is configured incorrectly - it's got a global context instead of a derived context for issue-level issues only.

Note that fixing issue 1 or 3 would be destructive - if you converted a task to a sub-task and back again, the original epic link data would be removed.  For that reason, I'd lean towards the middle fix - change the field so instead of "return value" when requested, it would be "if the issue is of sub-task or Epic type, return null, else return value"