I am looking for the best way of tracking the statuses of the same bug in multiple versions.
What is the best way to achieve this?
Has anyone considered using subtasks for this? Create a subtask for each release that the master bug needs to be fixed in, and then track each one that way. I realize that this creates a subtasking "limit" in that subtasks can be subtasked themselves. So if a bug actually needs to be broken into two or more subtasks, this becomes more difficult to manage (maybe impossible), but in our case, that rarely happens. Alternatively, you could create new issues that the master bug is "dependent" on which would also work (we did this in Bugzilla 3 where all we had were dependencies - there were no subtasks). Are there any subtask related limits (other than the 1 task, 1 set of subtask restriction) that might preclude doing this?
If you are not using subtasks already, you could create a subtask for each version to fix? You may have to specify more details of the subtask, but I think, this could be a good workaround for you!
edit: I saw that this answer was already given, so converted to a comment.
Has Attlassian come up with a better fix for this? It seems crazy to have to clone the issue multiple times which Jira already allows us to enter multiple Fix Versions on the ticket. Why are we allowed to enter mutiple Fix Versions on a ticket if we can not track them separately. I've been hoping for a fix to this that will allow us to have a separate status for an issue for each Fix Version. My problem with cloning is that is extremely kludgy and it causes my metrics to be out of whack. I have a single defect but my counts show 4 defects.
Attlassian, please consider this feature request and build it into the product so that I can have one issue ticket for multiple version and track separately. It happens all the time on all projects. I'm told TFS can do it.
Clearvision developed a plugin with your situation in mind which is available here.
It might not be exactly what you are after but it appears to fit the bill. The idea behind Jira Clones is that you need only raise a bug request for a single JIRA version and you can configure the plugin to automatically create issues across other versions based on your configuration. You are also able to choose which fields to sync so if you have extra reporting requirements We could possibly do it by syncing labels for example.
If you have any further questions about the plugin we would love to hear from you. (firstname.lastname@example.org)
I installed and configured this plugin but it still requires creating clones one at a time for each "Fix Version". What most of us are looking for is multiple clone creation with one-click. I feel this plugin is only a slight improvement over the out-of-box Jira clone feature.
Thanks for your feedback. The plugin has a configuration page which allows you to specify the fix versions you want to clone - and the versions you want to clone them for. Once you have configured the plugin and created the transition with the "create clones" post-function you should only need to click once to execute the transition.
In case it hasn't been clear before documentation is available here :
Does this match how you have been using it?
I did follow the directions in the JiraClones documentation and I did end up with a "Create Clones" option in my workflows tab. But to create clones for 4 "Fix Version(s)", for ex. 1.0, 1.2, 2.0 and 2.2, you have to first create an issue for 1.0, then open that issue and "Create Clone" for 1.2, open the 1.2 clone and create a clone for 2.0, then open the 2.0 clone and create a clone for 2.2.
The ideal situation would be that if there are multiple versions selected in the "Fix Version(s)" field then one click of "Create Clones" would create clones for 1.2, 2.0 and 2.2.
Duplicating information (cloning for each version) is not a feasable solution, doesn't scale at all. Still, looking for alternatives. At least in my case it should be enough to have some simple checklist for versions where it was fixed in, the rest of the information could be kept in the same bug.
Not sure if this sounds reasonable but another approach would be to have the duplicates on version level instead of issues so if you have "real" version 18.104.22.168 you could make "22.214.171.124_tofix", "126.96.36.199_toverify", etc. and use them instead of cloning issues.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs