• 6
    • 5
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      Atlassian Update - 23 April 2015

      Hi everyone,

      Thanks for voting and commenting on this issue. Your input in the comments helps us understand how this affects you and what you're hoping to accomplish with JIRA.

      At this time, this suggestion is not on the JIRA development roadmap. Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

      I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

      Regards,
      Dave Meyer
      dmeyer@atlassian.com
      Product Manager, JIRA Platform

      It would have been nice to be able to bulkchange subtasks when editing an Issue. F.ex. if I edit an issue and want to change Fix Version and Due Date, and my issue has 10 subtasks that I also want to change these fields in, it would be great to have a checkbox or something that says "Also change subtasks".

            [JRASERVER-9016] Bulk change subtasks

            bart slingerland added a comment - - edited

            removed

            bart slingerland added a comment - - edited removed

            Joe Cross added a comment -

            My problem is similar, but not explicitly stated here. I use Agile boards heavily and often use JQL filters to display tickets across multiple projects (e.g. One corporate initiative has tickets in several Jira projects and the sponsor wants one Agile board to look at, not 10). The problem I have is that there is no reasonable way to include sub-tasks, from multiple projects, in you Agile Work Board.

            Example:

            • Project A has a sprint that includes tickets relevant only to the team (e.g. code refactoring) AND to a corporate initiative (e.g. deliver dependency A to team Z)
            • Project B has the same situation

            There is no JQL that I can use to create an Agile Board that displays the sub-tasks relevant to the corporate initiative in both projects. If I use "project in (Project A, Project B)" I get the refactoring tickets. If I use "fixversion = 'Corporate Initiative'", I don't get sub-tasks because they don't inherit the FixVersion of the parent when you drag-n-drop on the Agile Plan Board. And I can't use "Epic Link" in my JQL because you can only set one Epic per ticket and I can't force teams to put all Corporate Initiative tickets into a single Epic or they lose a lot of value from setting their own epics.

            So what to do?? I can't think of any reason why a sub-task would not inherit the FixVersion from it's parent when it is dragged onto a version in the Agile Plan Board. It would be a gross violation of Scrum principles to say that the parent is being planned into a release, but the sub-tasks are in a different release.

            Joe Cross added a comment - My problem is similar, but not explicitly stated here. I use Agile boards heavily and often use JQL filters to display tickets across multiple projects (e.g. One corporate initiative has tickets in several Jira projects and the sponsor wants one Agile board to look at, not 10). The problem I have is that there is no reasonable way to include sub-tasks, from multiple projects, in you Agile Work Board. Example: Project A has a sprint that includes tickets relevant only to the team (e.g. code refactoring) AND to a corporate initiative (e.g. deliver dependency A to team Z) Project B has the same situation There is no JQL that I can use to create an Agile Board that displays the sub-tasks relevant to the corporate initiative in both projects. If I use "project in (Project A, Project B)" I get the refactoring tickets. If I use "fixversion = 'Corporate Initiative'", I don't get sub-tasks because they don't inherit the FixVersion of the parent when you drag-n-drop on the Agile Plan Board. And I can't use "Epic Link" in my JQL because you can only set one Epic per ticket and I can't force teams to put all Corporate Initiative tickets into a single Epic or they lose a lot of value from setting their own epics. So what to do?? I can't think of any reason why a sub-task would not inherit the FixVersion from it's parent when it is dragged onto a version in the Agile Plan Board. It would be a gross violation of Scrum principles to say that the parent is being planned into a release, but the sub-tasks are in a different release.

            so... how many more decades to wait for this super basic feature ?

            BarthélémyH added a comment - so... how many more decades to wait for this super basic feature ?

            Derek Hunter added a comment - - edited

            What you want to do is possible with the "Bulk Change Issues" feature on a search. I'll do the "Fix Version" example which I do all the time.

            • open a "search" on the issues that you want to change
              • usually this involves clicking on the "Fix Version" and getting a list
            • under "Tools" select "Bulk Change: all ( n ) issues"
            • check the boxes of the issues that you want to edit the fix version, click Next
            • choose "Edit" from the next page, click Next
            • edit the "Fix Version"
            • finish the wizard.

            This works for pretty much any field. I have even done this with a disparate set of JIRA issue numbers using JQL search as follows:

            id in (PROJECTA-563, PROJECTB-436)

            Derek Hunter added a comment - - edited What you want to do is possible with the "Bulk Change Issues" feature on a search. I'll do the "Fix Version" example which I do all the time. open a "search" on the issues that you want to change usually this involves clicking on the "Fix Version" and getting a list under "Tools" select "Bulk Change: all ( n ) issues" check the boxes of the issues that you want to edit the fix version, click Next choose "Edit" from the next page, click Next edit the "Fix Version" finish the wizard. This works for pretty much any field. I have even done this with a disparate set of JIRA issue numbers using JQL search as follows: id in (PROJECTA-563, PROJECTB-436)

            the issue was report 2006 - unbelievable that this is not implemented yet! I dont want to use a script or a plugin for this basic functionality.

            Raoul Jaeckel added a comment - the issue was report 2006 - unbelievable that this is not implemented yet! I dont want to use a script or a plugin for this basic functionality.

            KhongMingA added a comment -

            KhongMingA added a comment - https://answers.atlassian.com/questions/124677/howto-bulk-edit-change-all-subtasks The script there might be working.

            You may want to consider the JJUPIN plugin that introduces a Simple Issue Language

            The following example describes a the post function of "Start progress" transition (and leads the main task to status: In Progress) that also leads all subtasks to In Progress:
            http://confluence.kepler-rominfo.com/display/JJUP20/Recipe+-+Autotransitioning+subtasks

            You may perform any transition to the subtasks or set specific custom fields.

            Give it a try and download it from here: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin
            or from here http://jira-plugins.kepler-rominfo.com/x/product/id/3

            Florin Haszler (Alten Kepler) added a comment - You may want to consider the JJUPIN plugin that introduces a Simple Issue Language The following example describes a the post function of "Start progress" transition (and leads the main task to status: In Progress) that also leads all subtasks to In Progress: http://confluence.kepler-rominfo.com/display/JJUP20/Recipe+-+Autotransitioning+subtasks You may perform any transition to the subtasks or set specific custom fields. Give it a try and download it from here: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin or from here http://jira-plugins.kepler-rominfo.com/x/product/id/3

            boardtc added a comment - - edited

            We are using 4.2.2. One can find sub tasks easily doing "issuetype in subTaskIssueTypes() and parent = KEY-X" but not being able to move with a bulk edit is a pain. It sounds like there is no plugin solution to bulk edit move sub tasks to a new parent for 4.2.2 ?

            boardtc added a comment - - edited We are using 4.2.2. One can find sub tasks easily doing "issuetype in subTaskIssueTypes() and parent = KEY-X" but not being able to move with a bulk edit is a pain. It sounds like there is no plugin solution to bulk edit move sub tasks to a new parent for 4.2.2 ?

            I created a plugin that adds a new Parent Issue Key calculated field, that lets you enter a Parent Issue Key in a Filter, and retrieves all the Sub-Tasks for that parent issue. The results are in the Issue Navigator, so you can then perform a Bulk Edit on the Sub-Tasks.

            I also modified the .jsp file that displays the Sub-Task Table in a parent issue, and added a link to open all the Sub-Tasks in the Issue Navigator.

            We're still on 3.13.5, so not sure if 4.x already solves this. If there is still enough interest in this solution for 3.13.5, I'll look into posting to the plugin repository.

            -Cory

            Cory Sytsma added a comment - I created a plugin that adds a new Parent Issue Key calculated field, that lets you enter a Parent Issue Key in a Filter, and retrieves all the Sub-Tasks for that parent issue. The results are in the Issue Navigator, so you can then perform a Bulk Edit on the Sub-Tasks. I also modified the .jsp file that displays the Sub-Task Table in a parent issue, and added a link to open all the Sub-Tasks in the Issue Navigator. We're still on 3.13.5, so not sure if 4.x already solves this. If there is still enough interest in this solution for 3.13.5, I'll look into posting to the plugin repository. -Cory

            When in the Agile -> Task Board view that comes with GreenHopper, there is an option to view subtasks of a story that are in a particular workflow phase in the Issue Navigator (mouse over the subtasks area and you will get a little icon in the top right corner). From there it is easy to apply bulk changes to those subtasks.

            It would be nice if this same feature were available, perhaps in the dropdown menu of the Sub-Tasks section of the JIRA Browse view of a story.

            Julian Wood added a comment - When in the Agile -> Task Board view that comes with GreenHopper, there is an option to view subtasks of a story that are in a particular workflow phase in the Issue Navigator (mouse over the subtasks area and you will get a little icon in the top right corner). From there it is easy to apply bulk changes to those subtasks. It would be nice if this same feature were available, perhaps in the dropdown menu of the Sub-Tasks section of the JIRA Browse view of a story.

            The new advanced search feature can be used to find subtasks very easiliy:
            http://confluence.atlassian.com/display/JIRA041/Advanced+Searching?clicked=jirahelp#AdvancedSearching-Parent

            Regards, Per

            Per Spilling added a comment - The new advanced search feature can be used to find subtasks very easiliy: http://confluence.atlassian.com/display/JIRA041/Advanced+Searching?clicked=jirahelp#AdvancedSearching-Parent Regards, Per

            Niki C added a comment -

            Any updates on this issue?

            Niki C added a comment - Any updates on this issue?

            Just the option to search on a Issue Key and find all related issues if that is linked, related, depended, child of the issue or the issue itself ..
            Could be all implemented just in the search issue screen.

            Arno Koehler added a comment - Just the option to search on a Issue Key and find all related issues if that is linked, related, depended, child of the issue or the issue itself .. Could be all implemented just in the search issue screen.

            Hey Paul,
            Have you tried bulk moving taks to subtasks, like its done in MS Project?
            If yes could you please share the input?
            Thanks
            Vk

            Vick Keshav added a comment - Hey Paul, Have you tried bulk moving taks to subtasks, like its done in MS Project? If yes could you please share the input? Thanks Vk

            PaulC added a comment -

            Hi Ken, im very interested in how you set up your listener.
            Are you able to share anything? :o)

            I havent tried listeners yet, but one way which might help is to create a new custom field called "Parents Key", and to have this field visible on the subtasks issue type screen.
            This way you can make the field mandatory, and whenever people create a subtask, thye just paste in the parent key, eg jira-9016.

            Then you can set up a filter to show all items belonging to that parent key, and do a bulk change on them.
            (also comes in handy in case someone moves the case by mistake, of it the subtask becomes un-associated with the parent by some means or corruption etc, so that you can easily identify which parent case need to sit under).

            There might be a way for that value to be initially auto-populated upon creation, based on which case was the parent, but Im not sure yet.

            regards,
            Paul

            PaulC added a comment - Hi Ken, im very interested in how you set up your listener. Are you able to share anything? :o) I havent tried listeners yet, but one way which might help is to create a new custom field called "Parents Key", and to have this field visible on the subtasks issue type screen. This way you can make the field mandatory, and whenever people create a subtask, thye just paste in the parent key, eg jira-9016. Then you can set up a filter to show all items belonging to that parent key, and do a bulk change on them. (also comes in handy in case someone moves the case by mistake, of it the subtask becomes un-associated with the parent by some means or corruption etc, so that you can easily identify which parent case need to sit under). There might be a way for that value to be initially auto-populated upon creation, based on which case was the parent, but Im not sure yet. regards, Paul

            Ken Roland added a comment -

            I think they mean a bulk change ability directly from the parent issue view.

            I'm looking at this now too. We have some issues that have 20 or more subtasks. When you need to change just those sub tasks it can be a major hassle. The issue navigator has no easy way to "Find by Parent issue" to show only those 20 subtasks out of the hundreds.

            I've implemented a listener now that updates subtasks on parent modification. So if certain fields are changed on the parent it automatically updates sub-tasks to the same. (Fix Version, Components, etc.)

            What I'd like now is an "Edit" button in the sub-task list to save on the time to edit a sub-task. And a way to sort by Priority would be good ... I guess I'll be adding a lot now that I think about it.

            Ken Roland added a comment - I think they mean a bulk change ability directly from the parent issue view. I'm looking at this now too. We have some issues that have 20 or more subtasks. When you need to change just those sub tasks it can be a major hassle. The issue navigator has no easy way to "Find by Parent issue" to show only those 20 subtasks out of the hundreds. I've implemented a listener now that updates subtasks on parent modification. So if certain fields are changed on the parent it automatically updates sub-tasks to the same. (Fix Version, Components, etc.) What I'd like now is an "Edit" button in the sub-task list to save on the time to edit a sub-task. And a way to sort by Priority would be good ... I guess I'll be adding a lot now that I think about it.

            PaulC added a comment -

            Hi Guys,
            I like subtasks, but I tried a test with bulk changing them, and it lets me delete or edit multiple ones.

            Which version have you tried this on? Recent version seems to support this.

            regards,
            Paul

            PaulC added a comment - Hi Guys, I like subtasks, but I tried a test with bulk changing them, and it lets me delete or edit multiple ones. Which version have you tried this on? Recent version seems to support this. regards, Paul

            We are using subtasks in the same way as Andy reported. With the feature to change any already reported issue to be a subissue we like using subtasks to group things.
            Subtasks also give the opportunity to easily do a more detailled feature-planning than using linked items without loosing the overview.

            Gerald Innerwinkler added a comment - We are using subtasks in the same way as Andy reported. With the feature to change any already reported issue to be a subissue we like using subtasks to group things. Subtasks also give the opportunity to easily do a more detailled feature-planning than using linked items without loosing the overview.

            Will Rau added a comment -

            Has anyone seen or written a plugin to do this?

            Will Rau added a comment - Has anyone seen or written a plugin to do this?

            We set up a workflow so that every new feature would get a standard set of subtasks (create design, implement feature, write test plan etc) but it was too painful to manage the subtasks this way. Some examples include:

            1. Moving a new feature to a different release meant manually moving all of the subtasks
            2. Resolving a feature meant first manually resolving all of the open subtasks
            3. Fixing the component on a new feature meant manually changing each subtask to use this feature

            We have now decided to back away from subtasks and to use linked issues instead. This is actually more natural, as often the subtasks have already been reported as standalone issues. Now that we are switching away from subtasks, I'm finding it painful that there is no easy way to bulk delete subtasks too! So now I have to manually delete the eight subtasks for each of the tasks that we set up this way.

            More than ever I'm of the opinion that subtasks were a mistake and that instead the linking mechanism should be beefed up to support the same functionality. So I'd like to see 'bulk change linked issues' as an equivalent tool to whatever is done here.

            Andy Armstrong added a comment - We set up a workflow so that every new feature would get a standard set of subtasks (create design, implement feature, write test plan etc) but it was too painful to manage the subtasks this way. Some examples include: Moving a new feature to a different release meant manually moving all of the subtasks Resolving a feature meant first manually resolving all of the open subtasks Fixing the component on a new feature meant manually changing each subtask to use this feature We have now decided to back away from subtasks and to use linked issues instead. This is actually more natural, as often the subtasks have already been reported as standalone issues. Now that we are switching away from subtasks, I'm finding it painful that there is no easy way to bulk delete subtasks too! So now I have to manually delete the eight subtasks for each of the tasks that we set up this way. More than ever I'm of the opinion that subtasks were a mistake and that instead the linking mechanism should be beefed up to support the same functionality. So I'd like to see 'bulk change linked issues' as an equivalent tool to whatever is done here.

              Unassigned Unassigned
              51fb7511af20 Morten Kristiansen
              Votes:
              143 Vote for this issue
              Watchers:
              71 Start watching this issue

                Created:
                Updated: