Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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

1 comment

>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"

Like Mike Larsen (AgC) likes this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Posted in Jira Core

How to manage many similar workflows?

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

4,565 views 12 8
Join discussion

Community Events

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

Events near you