Allow features to be linked to existing JIRA issues

Implemented! Hooray!!!

Is there an article or documentation link that explains how it works? (I expect Aha is overwritten upon connection?)

Thank you!

What I need is that when I take the action of "Send to Jira" that if that exact issue already exists in Jira to just establish a link between the Aha object and the existing Jira object instead of creating a duplicate issue.

You can remove the JIRA link from a feature (or requirement or release) by hovering over the link and clicking the trash icon that appears. This will not remove the Aha! Reference field from the issue in JIRA, but will stop any updates in either direction. It will also allow you to send the feature to JIRA again and create a duplicate issue.

On a related note, I also want to be able to tell a feature to "forget its link to Jira" , so far, it seems to be a permanent link

Existing comments are never copied when we send a feature from Aha! to JIRA and this linking process would work the same. Existing comments would not be synced.

Attachments are always merged - we never delete attachments - so the attachments from both systems would be kept (unless they have the identical name and size, in which case only one copy will be kept).

I would like the option to decide when linking the issue.

Also, do you expect that comments and attachments would be overwritten by the master or would they be merged together?

If not configurable, I would prefer JIRA be the master copy in the initial synchronization, overwriting Aha. A dismissible warning may also make sense to ensure the behavior is understood. 

One challenge with linking existing items is that for two-way synchronization to start working one version of the item needs to become the "master".

So if you link an Aha! feature with a JIRA issue any fields in Aha! which are different than JIRA will be overwritten with the values from JIRA. From that point all changes will be synchronized, so further changes in Aha! will be reflected in JIRA.

The practicality of your users is very likely no different than what we're going through. A team is trying to represent stuff in JIRA and *then* discover Aha and *then* want everything to look pretty. Additionally, some sub teams prefer to work out their details in JIRA first, then pull into or pair up with stuff that's been prepared in Aha. It's probably an ideal and an unlikely scenario that a team will exclusively build stuff in Aha first then push it to JIRA for first time to create items. It's always going to be a hodgepodge :)