• 214
    • 90
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      We do internally developed software capitalization, and our time tracking must align to the epics teams are working on (in our world, epic=project). Because of this, we require all issues to be tagged to an epic. Sub-tasks cannot be viewed in the Plan mode, and therefore cannot be tagged to the epic. In addition, when I create a sub-task, it is not inheriting the Epic link from the parent.

      This causes our time reporting to create orphaned hours for sub-tasks which have no epic.

      When sub-task is created, it doesn't inherit the Epic link from the parent. This creates some issues, like:

      • If a board is configured to use Epics swimlanes and you have visible on this board an Epic, and under this Epic a story and a sub-task under this story, if by some reason the story is not visible on the board (due to filter conditions or status mapping configuration), the sub-task is displayed under the "Issues without Epics" instead of being displayed under the Epic linked to its parent
      • This also causes time reporting to create orphaned hours for sub-tasks which have no epic.

      Defining sub-tasks to inherit their parents' Epic link would resolve both problems

      Please expose the sub-tasks in plan (or make it configurable), or ensure the epic link field inherits the epic attributes of it's parent!

      Possible workaround

      I thought of creating an Automation rule that will populate a paragraph custom field in the Sub-task with a link to the Epic that's associated to the parent of that Sub-task.

      • Then I first created an Automation rule that will populate that field upon a Sub-task's creation if the parent of the Sub-task contains an Epic:
        Show Epic on Sub-task - creation.json
        • First check if the issue type is Sub-task -> then check if the parent has an Epic by looking if the smart value to get the parent's Epic is not empty -> then edit the paragraph field I created with the following smart value (it will get the parent's epic's summary and key, as well as create a URL using wiki markup):
          [{{issue.parent.epic.key}} - {{issue.parent.epic.summary}}|https://unlimitedjiraworks.atlassian.net/browse/{{issue.parent.epic.key}}]
          
          • You will need to adjust the URL to match your site's
      • Result in the Sub-task:

      I also create a rule that will perform the changes when the Sub-task's parent is edited (Epic added or removed): Show or remove Epic on Sub-task - edit.json

      • The rule will look at changes of the field Parent -> Then check if it occurred on specific issue types (I selected issue types that are below Epic in my hierarchy) -> Then execute an if/else to see if the Parent field is now Empty or not
        • If Empty, clear the field Epic in the Sub-tasks
        • If not Empty, populate the field Epic in the Sub-tasks

      I built those rules for a scenario where it is assumed that the parent of the Sub-task will have a parent of type Epic. With some tweaks it could be possible to make it work for others Parent/Child relationships within the hierarchy.

      You might also want to use this documentation as reference for importing the Automation rules I provided: Import and export Jira automation rules.

            [JSWCLOUD-8181] Sub-tasks should inherit the Epic Link of their parent

            Any update on this? 

            Claire Brandon added a comment - Any update on this? 

            hello jean.resener 

            Multiple customers are requesting for status update on this raised FR. Could you please help with any tentative timeline so that we can keep the customers updated. 

            Regards

            Dipankar

            Dipankar Srigyan added a comment - hello jean.resener   Multiple customers are requesting for status update on this raised FR. Could you please help with any tentative timeline so that we can keep the customers updated.  Regards Dipankar

            Ankita Khandelwal (Inactive) added a comment - https://getsupport.atlassian.com/browse/JST-736495

            Hi there,

            With the latest version of Exocet, you can copy the links of the parent issue when you create a sub-task.
            You just have to configure an operation like this:

            and all the sub task that you'll create with this operation will be linked to the parent issue epic!

            Of course, you can add condition to have this operation available only where you want it.  

            Christophe Promé added a comment - Hi there, With the latest version of Exocet , you can copy the links of the parent issue when you create a sub-task. You just have to configure an operation like this: and all the sub task that you'll create with this operation will be linked to the parent issue epic! Of course, you can add condition to have this operation available only where you want it.  

            We've just added the ability to do this with Automation for JIRA! It is simple to add a rule that listens for sub-task creation and then sets the Epic Link from the parent.

            The rule would look something like:

            This was done as part of work to make related issues easier to work with. For more details see https://blog.codebarrel.io/synchronize-parent-and-sub-task-issues-with-automation-for-jira-bdcca6c9d453

            Nick Menere added a comment - We've just added the ability to do this with  Automation for JIRA ! It is simple to add a rule that listens for sub-task creation and then sets the Epic Link from the parent. The rule would look something like: This was done as part of work to make related issues easier to work with. For more details see  https://blog.codebarrel.io/synchronize-parent-and-sub-task-issues-with-automation-for-jira-bdcca6c9d453

            This should be done. Its would be a great bonus for all using Jira. This improvement will allow the overall status to be checked on instead of only seeing the parent issues. Right now we have no clue as to what is happening to the subtasks unless we go into each parent to check.

            Come on Atlassian you can do better than this

            Stephen Morning added a comment - This should be done. Its would be a great bonus for all using Jira. This improvement will allow the overall status to be checked on instead of only seeing the parent issues. Right now we have no clue as to what is happening to the subtasks unless we go into each parent to check. Come on Atlassian you can do better than this

            CinziaS added a comment -

            Much needed improvement to sort issues in queries in a way that can be logically read by a human

            CinziaS added a comment - Much needed improvement to sort issues in queries in a way that can be logically read by a human

            This is a great idea. If implemented please implement in Kanban as well as Scrum.

            Thanks!

            Blake McMillan added a comment - This is a great idea. If implemented please implement in Kanban as well as Scrum. Thanks!

            Laurence - we are using Tempo combined with the new epic support. With this configuration, you can pull worklog reports that provide the epic link for each issue time was logged towards. With sub-tasks, you get the parent issue id, so you have do an extra step of looking up the epic link for the parent and adding it to the file. Then you can get a roll-up of all hours. Hope this helps.

            Jean Resener added a comment - Laurence - we are using Tempo combined with the new epic support. With this configuration, you can pull worklog reports that provide the epic link for each issue time was logged towards. With sub-tasks, you get the parent issue id, so you have do an extra step of looking up the epic link for the parent and adding it to the file. Then you can get a roll-up of all hours. Hope this helps.

            +1.
            in the meantime, how does anybody manage to get any stats for total number of hours per epic?

            laurence bascle added a comment - +1. in the meantime, how does anybody manage to get any stats for total number of hours per epic?

            I would also like to see sub tasks inherit the epic from their parent.

            We use projects to separate out key distinct systems, so we're looking to use Epics as significant projects, broken down into many Stories, and the Stories are broken down into sub tasks.

            As a manager, I'd like to be able to see statistics for completed/remaining tasks in an Epic, rather than just direct descendants of an Epic. Additionally, I'd like the issue search to be able to filter by Epic to return everything associated with that Epic, both children and grand-children.

            Finally, it would be good when viewing an Epic, to be able to hide closed tasks or at least sort by issue status.

            I think most of these things would be relatively trivial once the sub-tasks inherit their parent's Epic.

            Craig Douglas added a comment - I would also like to see sub tasks inherit the epic from their parent. We use projects to separate out key distinct systems, so we're looking to use Epics as significant projects, broken down into many Stories, and the Stories are broken down into sub tasks. As a manager, I'd like to be able to see statistics for completed/remaining tasks in an Epic, rather than just direct descendants of an Epic. Additionally, I'd like the issue search to be able to filter by Epic to return everything associated with that Epic, both children and grand-children. Finally, it would be good when viewing an Epic, to be able to hide closed tasks or at least sort by issue status. I think most of these things would be relatively trivial once the sub-tasks inherit their parent's Epic.

            Jason Skidis added a comment - - edited

            If this feature is to be implemented in the future, please make it a configurable option. I would not want this behavior. In our usage of Greenhopper we would have no cases where sub-tasks of the same parent issue would have different epics so linking the subtasks to an Epic would be redundant (to determine the Epic that a sub-task one "belongs to" one only has to determine the Epic of the parent issue). This redundancy would cause us to perform extra effort in our shared filters (to exclude subtasks) that we use to show stakeholders issues related to an Epic(s). Subtasks would be "how we make the sausage" extraneous information that we don't wish to share with our stakeholders and they quite frankly wouldn't want or know what to do with.

            Jason Skidis added a comment - - edited If this feature is to be implemented in the future, please make it a configurable option. I would not want this behavior. In our usage of Greenhopper we would have no cases where sub-tasks of the same parent issue would have different epics so linking the subtasks to an Epic would be redundant (to determine the Epic that a sub-task one "belongs to" one only has to determine the Epic of the parent issue). This redundancy would cause us to perform extra effort in our shared filters (to exclude subtasks) that we use to show stakeholders issues related to an Epic(s). Subtasks would be "how we make the sausage" extraneous information that we don't wish to share with our stakeholders and they quite frankly wouldn't want or know what to do with.

              Unassigned Unassigned
              jean.resener Jean Resener
              Votes:
              145 Vote for this issue
              Watchers:
              104 Start watching this issue

                Created:
                Updated: