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.

  • Danny Archer
  • Oct 21 2015
  • Likely to implement
Release time frame
  • Attach files
  • Petr Nový commented
    February 18, 2016 09:41

    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.

  • Paulo Branco commented
    September 28, 2016 16:08

    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

  • Matt Vlasach commented
    January 18, 2017 19:00

    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 :(

  • Joseph Abromaitis commented
    May 2, 2017 13:03

    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. 

  • Paulo Branco commented
    June 22, 2017 13:33

    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

  • Gus Rivera commented
    April 11, 2018 17:43

    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.

  • Hugo Loza commented
    April 11, 2018 21:06

    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?