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.
|Release time frame|