Skip to Main Content
Status Shipped
Categories Jira
Created by Chris Waters
Created on Oct 22, 2014

Allow features to be linked to existing JIRA issues

If we already have issues in JIRA that are duplicates of features in Aha! we want to be able to manually create a link between them.

  • Attach files
  • Guest
    Reply
    |
    Apr 17, 2015

    Implemented! Hooray!!!

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

     

    Thank you!

  • Aaron Bawcom
    Reply
    |
    Jan 23, 2015

    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.

  • Admin
    Chris Waters
    Reply
    |
    Jan 22, 2015

    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.

  • Guest
    Reply
    |
    Jan 22, 2015

    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

  • Admin
    Chris Waters
    Reply
    |
    Oct 27, 2014

    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).

  • Tim Santos
    Reply
    |
    Oct 27, 2014

    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?

  • Guest
    Reply
    |
    Oct 27, 2014

    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. 

  • Admin
    Chris Waters
    Reply
    |
    Oct 27, 2014

    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.

    I am interested in any feedback on this? Should Aha! overwrite JIRA when you first link items, or should it be the other way around?
  • Brian Link
    Reply
    |
    Oct 23, 2014

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