RELATED IDEAS
Allow for a master release and its sub-releases to link to one jira version
More details
In Aha, you are allowing for a use case where the master release and its sub-releases are essentially the same.
You change the name, the internal date, the external date on the master release - and it updates the sub-releases.
I think there's a use case where the versions in jira are the same, too - since the master and sub-releases are all the same release in Aha, there could be a situation where they are all the same version in jira also.
How Should it Work
I'm sure the impact is bigger than this, but the following approach would fix our immediate sync problem (see Why is it userful for more details)
Basically, when a jira webhook sends updates for a feature to Aha, make the update based on matching the feature key, and then matching on the release key (rather than the other way around).
Right now it looks like Aha takes the webhook data, and rather than trying to find the matching feature, it tries to find a matching release, and then tries to update the feature in that release.
We know that a feature in Aha really needs to link to a unique issue in jira.
Of course, this does not accommodate the use case where someone creates a new feature in jira (where features are matched to epics) - if the jira version matches to multiple releases in Aha, it will just have to pick one.
However, for me, I think this is more of an edge case (features will normally originate in Aha) than the master/sub-releases matching to one jira version.
Or, if a release really only can match to one jira Version, there should be an error message or warning, letting the user know that an Aha master release and its sub-releases can't sync with the same jira version.
Why is it useful
Right now, we created a product line with multiple products, and created a master release and sub-releases in each product. We've got one big engineering team / sub-teams working on the entire product line, out of one jira project.
The sub-releases in Aha all link to the same jira version.
When we move a feature from 1.7 to 1.8 in Product A in Aha, it updates the feature in jira with the correct version. Perfect.
But that triggers a jira webhook update where it sends the data back to Aha - that the feature has moved to a new version. Instead of finding the feature and updating it, it looks for the release. And since we're using the same release across the entire product line, it takes the first release it finds (in Product B), and creates a brand new feature in that release.
This duplicates the feature in Aha (original in Product A, duplicate in Product B), amplifying our sync issues.
Was this capability (requested in the comment of April 25 2017 finally added?
The fix that Chris describes below fixes the sync-ing issue but we still need to link sub-releases to one jira release version. Is that in the works? I understand that more flexible jira integration is coming (where we will be able to sync Aha release with custom field in jira). However, we want the jira field to be populated with the master release, not the sub-releases.
Thanks, Chris, you're a life saver - we were about to stop syncing the
release / versions in our largest product line, which would have been
unfortunate. It looks like we're all good now, though. Thanks again!
~Patty
I believe this can be solved with a simple fix. Currently when auto-importing Aha! doesn't consider that an issue in JIRA may have been created by an integration in Aha! that is for a different product. We are going to tweak the code so that Aha! will never auto-import an issue that already exists in Aha!, regardless of whether it is in the same product or not.
In response to Jeremy - yes!
Although, specifically, it's really the integration behavior with jira that we need changed.
We would like all of the products in our Customer Apps product line to be able to use one release, both in Aha and in jira.
For some reason one release in Aha can be replicated across all products in a product line (i.e. a master release at the product line level and sub-releases at the product level), but they need to link to different versions / releases in jira.
I think this would be helpful to us. The challenge is when a team is working on multiple products. Our general problem is that product lines don't carry the same feature set as products. Simply put, we want product lines to behave almost as if they are one giant product. Not sure if this is what you were getting at here, but those are my thoughts.