RELATED IDEAS
Need configuration to allow allow/block execution system (JIRA) initiated Epics back to Aha
For Epics which get initiated in Aha and flow down to JIRA, we want to enable 2-way integration so that updates which happen in JIRA are realized in Aha. However, if a NEW Epic is initiated on the JIRA side, we may not want that to be visible in Aha. For example - we have 'base product' Epics which flow down from Aha to JIRA and we need integration on those. We have other 'customer specific' Epics (distinguished by base/custom radio button) which we don't want coming back into Aha. It's not always feasible to leverage a new JIRA issue type for this.
-
ADMIN RESPONSEFeb 28, 2018
Thank you for your idea. With our enhanced Jira integration, any new issues created in Jira will appear in the Integration updates window as options to be imported. For new epics which should not be imported, you can select them and choose Ignore selected.
© 2024 Aha! Labs Inc.•All rights reserved
Austin - I'm aware that the new integration shows the new Epics in the integration updates window, but there is no capability to prevent someone from accidentally importing them, and frankly - it creates some confusion because there's no way to easily identify those which are wanted vs unwanted back in Aha. The ask here is to all a configuration to block the Epic from even making it that far upstream. We don't want them even coming into the integration update window as they shouldn't be there at all. The problem I see is that the integration automatically assumes that updates to epics as well as new epics should be sent back and what I'm saying is that there should be a differentiation between those two a they are not the same use case.