Map Jira's "Won't Fix" resolution status to Aha!s "Won't implement" status

We are looking to have our product team only in Aha and not living in Jira. The lack of being able to send a resolution is a definite blocker for that to happen.

Ideally the status would also determine the resolution (Done, won't fix, duplicate etc).

The ability to import the JIRA Resolution is a big step forward (and I think the one-way mapping is sufficient), but it still does not allow us to cleanly map into the Aha status. In JIRA, we just get the status "Closed" and the nuance goes into the Resolution. What we need to be able to do is to set the Aha Status based upon a combination of JIRA Status and Resolution. With this, we could be able to set a "Ready to Ship" status in Aha for Closed JIRA items with a Resolution of "Fixed" or "Done" and differentiate that from Closed JIRA items that have a Resolution of "Won't Do" or "No Fix Required" (which could then be mapped to Will Not Implement in Aha. Granted, that is a bigger set of functionality, but that is the ultimate solution here. The only work-around I have now is to map JIRA Closed to "Ready to Ship" then manually change the status in Aha based on the Resolution. This also means I can only sync Aha Status from JIRA, not bi-directionally...

Hi Kelly,

in many if not all cases, resolution is a mandatory field in JIRA on status transition.

So I am thankful that you want to monitor the need for it in terms of "people want to set certain value", however the problem is that when it is required by JIRA, it prevents the status transition synchronization.

So this is a situation when aha can not synchronize status change at all (e.g. in development -> closed). Not a wish for nice to have feature.

Thanks, Daniel! We are going to leave this idea open and continue to monitor customer need for a two-way sync of the Jira resolution field. Hopefully the one-way sync that we just released will be helpful in the meantime.

Hello admin, thanks for your response. The key bottleneck still remains, though. We have epics linked to features and when setting resolution is mandatory on transition in JIRA (fairly default scenario), then inability of aha to do aha -> JIRA synchronization of the field prevents us from changing epic status. This needs a full solution.

I agree as well. If at a minimum we could synchronize Resolution then the Aha content would at least be able to differentiate the different "closed" states from JIRA. Ideally it would be nice to map the resolutions to specific Aha status values.

Yep, our teams like to set specific resolutions for when we close things

Definitely a big problem when it comes to Jira integration. It would be great to be able to expose the resolution status, and also add some status transition logic in Aha!. The best workaround I've found (which is quite messy indeed) is to add a new 'Won't implement' status in Jira, with a transition that sets the resolution status to 'Won't Do'.  Shouldn't make a huge difference in Jira if you adjust your board filters to ignore the 'Won't implement' status just like  the Closed status. 

As our engineering team requires the Resolution field in Jira to be required when closing out an Issue, we need the ability to create a custom field in Aha! and map it to the Resolution field in Jira, so we can specify the reason why a Feature in Aha! is being set to "Will not implement". It is a good idea for us to track and report, in Aha!, the reasons why a Feature was not implemented.

My team just ran into this issue and it's completely halted our integration. We require a field at the close of a JIRA project which is what is breaking the links. We cannot un require that field because we need to report on that data and we struggle to get those fields populated without a requirement. However requiring that field breaks the integration so we're stuck. If anyone has any ideas on possible workarounds we're all ears!

Absoutely necessary. This makes JIRA sync basically unusable as there are so many constellations of stars with JIRA resolution configuration when it does not work, that it must be an issue for most of AHA customers. I consider this more than a design flaw then new feature request. This is a comment coming from experience with aha and JIRA, no theory.

This comment is for the request of the 'Resolution status' from JIRA.

We have several projects that need to have a workflow which has a Resolve Screen. With a Resolve screen, there would be  multiple conditions and validators. As part of the validators, there would be a check to see if there is a 'Resolution' field chosen from a list of options.

We have a 2 way sync between Aha and JIRA. When we mark a feature on Aha as shipped, it needs to mark the corresponding Epic on JIRA as Done. Now, this never happens because, there is an integration update error on Aha, that says "'resolution': Could not find valid 'id' or 'name' in resolution object.". So, basically even after removing the validator on JIRA workflow for the resolve screen, this doesn't work. 

Also, on a similar note, on JIRA, we have an IN REVIEW state, which is mapped to Ready-to-ship state on Aha. This transition also never goes through from Aha to JIRA, as there is no Reviewer field in Aha for a feature. And on the screen to move a JIRA ticket from some status to IN REVIEW, there is a validator that ensures a Reviewer is assigned for the ticket. So, again, this state transition from Aha never makes into JIRA. 

If there is a supported integration on Aha for JIRA, it needs to support these basic functionalities.

It needs to be higher level than this. We have to be able to map to the resolution field otherwise how can you complete a ticket in Aha and have it reflected in JIRA when a resolution has to be set upon closing.

Can we include the webhook to a transition post function in jira, and Aha process the json response?

On resolve screen most probably.

Some of our users get confused because the case shows as ready to ship but in fact we didn't do it.

I also agree with this proposal to map Jira's "Won't Fix" to Ana's "Won't implement".

I also agree that it would be great to also access Jira's Resolution, in Aha.  We have multiple Resolutions in Jira, and it's a real limitation to not be able to see that in Aha.

Thanks!

Agreed.  It would be great to also access the Resolution from Jira.