Skip to Main Content

Share your product feedback

Status Future consideration
Categories Jira
Created by Danny Archer
Created on Oct 21, 2015

Handle multiple FixVersions in JIRA

An Aha! feature can only be associated with a single release, however it is common for development teams to associate multiple fix versions with a issue in JIRA.

Currently, the Aha! feature will overwrite the fix versions in JIRA if the fix versions do not align with Aha! as the master copy. This causes problems when the intended workflow in JIRA is to have the feature associated to the fixversion -> Aha! release + another fix version used for internal tracking purposes.

  • Attach files
  • Dmitro C
    Reply
    |
    Jun 15, 2023

    Releases (and hence jira fixversions) can be multiple per week and epic/feature is delivered incrementally by them. Currently, Aha! doesn't support the view which releases the feature would be delivered by, as 1 aha epic maps to only 1 jira fixversion

  • Garret Duffy
    Reply
    |
    Jun 7, 2023

    Critical blocker for us, JIRA Fix Version is already used by Dev team and AHA Release is for separating Phases. If the AHA Release overwrites the jira fix version, this is not good.

  • Vitor Lory
    Reply
    |
    Nov 13, 2020

    In our case, we have multiple fix versions for different products for the same Epic and Story. We want to use bi-directional integration, but this causes data loss in JIRA.

    I was trying to link a custom field with a custom Releases field in the feature, but I wasn't able to choose this specific custom field for integration.

    Since this idea has been on for 5 years, I wonder if:

    1. there is any workaround for this

    2. we are really going to get it as it is set for Future Consideration.

    1 reply
  • Guest
    Reply
    |
    Jun 3, 2020

    YES PLEASE this is a critical blocker in our use of Aha as a reporting tool.

  • Guest
    Reply
    |
    Dec 20, 2019

    This is a major problem, because fix versions are also used for release burndowns, and now this impacts JIRA functionality on reporting. 

  • Agnes Muller
    Reply
    |
    Oct 28, 2019

    This is really annoying. It makes it impossible for us to add in the fixversion in Jira the version of the component where it's delivered - this version is necessary for product delivery tracking

  • Guest
    Reply
    |
    Jun 14, 2019

    This is really annoying. Aha! overwrites our software release versions set by our CI/CD system with planning releases. This really should be fixed. Especially since the solution is spelled in the comments. Are tehere any viable workarounds?

  • Hugo Loza
    Reply
    |
    Apr 11, 2018

    Really frustrating that AHA! just wipes out all fixVersions and set to just one. That breaks cross version feature implementations. Also suprised that this request stills open since 2015, and was not yet implemented. Any chance to have this fixed in the near future?

  • Gus Rivera
    Reply
    |
    Apr 11, 2018

    This wiped out many of our fix versions.  Frustrating data loss; besides the fact that we have to hack our process to accommodate Aha limitation of a single release version for an issue.  That is not our reality.

  • Guest
    Reply
    |
    Jun 22, 2017

    When will this idea be implemented? This limitation forces us to not send the release info to JIRA which means our developers have to look at two different places to see the target release.

    Please prioritize this idea!

    thank you

  • Joseph Abromaitis
    Reply
    |
    May 2, 2017

    Must have in our world. The first time I sync'd Aha to Jira it wiped out all my QA build numbers! Which we also use in the fixVersion field in Jira. And continues to do so every time a feature is updated. Agreed on the below comments, it would be best if it appended the fixVersion, not replace it. 

  • Matt Vlasach
    Reply
    |
    Jan 18, 2017

    It seems wrong that the AhA implementation would handle a foreign data field (in JIRA) as a 1:1 type when it is fundamentally 1:N.  As Peter pointed out, it should be using ADD/REMOVE instead of SET.

    If not fixed, this should be called out in the configuration instructions pretty clearly as data loss can easily result, which is exactly what happened in our case :(

  • Guest
    Reply
    |
    Sep 28, 2016

    Hi, this is not an acceptable workaround.  Aha version should be sent to JIRA to show our release planing, but developers should be able to enter in the actual release code version.  This is even more important if they are doing silent releases which users can't see yet.  They manage that through the code, but the users only see the feature after it has been released. 

    thanks

    Paulo

  • Guest
    Reply
    |
    Feb 18, 2016

    Hello, Fix for this problem might be easy. Aha! just need to adjust API call from Aha! to JIRA. It is necessary to use ADD/REMOVE versions, instead of using SET which overwrites all. JSON coming to JIRA then might looks like this :

    { "update": { "fixVersions": [ {"add": {"name" :"New version"}}, {"remove": {"name" :"Version A"}}, {"remove": {"name" :"Version B"}}, {"remove": {"name" :"Version B"}}, {"remove": {"name" :"Version C"}}, {"remove": {"name" :"Version D”}}] } }

    New version  is intended version while version A - D are remaining versions in Aha! This will make sure that Aha! will manipulate only versions handled in Aha! while leaving Dev versions (handled only JIRA) alone.

    I am convinced that this feature will be super easy for implementation.