Handle multiple FixVersions in JIRA

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

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.

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.

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

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

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

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?

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?

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.

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

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. 

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

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

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.