Skip to Main Content

Share your product feedback

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
      Drop here to upload
    • Guest
      Reply
      |
      Feb 7, 2025

      Please enable the Aha! release field to support multiple fix versions, as our Jira features and stories use bi-directional mapping. Kindly consider this as high priority one.

    • Rathishan P
      Reply
      |
      Feb 5, 2025

      We are using multiple fix versions in Jira for our Product Features and Stories and the mapping with Aha! for fix version is bi-directional. This cause data loss in Jira or Aha!. Please make the Release field in Aha! to support multi "Releases or fix versions.

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