Skip to Main Content
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 to 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
  • Vitor Lory
    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.

  • Guest
    Jun 3, 2020

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

  • Guest
    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
    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
    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
    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
    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
    Jun 22, 2017

    When will this idea be implemented?   This limitation forces us to not send the release infoto 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
    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
    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
    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. 



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