When using the JIRA Tempo plugin to track work time, it is useful to link issues to Accounts - for this the plugin exposes a custom field named Account. This field, formerly called Billing Key, is used among others in reporting, to decide which customer/project/order should pay for the work involved in resolving an issue.
After experimenting a bit, it seems that the Account field is special, and Aha is unable to set it properly. Error messages indicate it should be a numeric field in Aha, however even when it is mapped this way, and correct keys are passed, JIRA issues are created with Account equal None.
Proper Feature/Requirement billing is quite crucial for us when doing strategic planning.
Thank you for the request. At this time, based on current priorities and community feedback, we are unlikely to make updates in this area. We hope you can understand.
This issue is driving a wedge in our commitment to continue using Aha due to the manual workarounds required to track which team is working on a ticket.
I figured out a way to make this work. It's a little kludgy but it works better than getting rid of Aha.
I know this is bit cumbersome but for us we're basically tracking all these features to a single account so I just know that each new feature for my web app is 3 and each new feature for my mobile app is 5. Those are the "Engineering" accounts I have setup in Tempo. I suppose this is no different than coding any transaction in your accounting package.
You you have the original feature created and it transfers to Jira you won't have any problems with syncing until you add a new requirement.
Hope this helps someone!
This is much needed and a great idea
Ack. I just noticed the "unlikely to implement".
That's a real bummer. Is this really that hard????
Jira Webhook(JWH) sends out notifications.
Aha! receives notifications.
JWH sends out "different" notifications for Tempo than for standard Jira.
Solution: Add additional JWH processing code to look for an handle "different" output from Tempo.
I've got to believe this is a day or two of work to just A) handle different tags not currently handled B) extract the relevant data, C) do what is normally done with standard jira notifications.
Sure, developer schedules are busy.. but this could be a low-hanging fruit sort of thing..
I lost pretty much an entire day trying to figure out what I was doing wrong..
I finally got a super helpful support engineer (Kudos Randy Ayers), but the end of the story was that Tempo doesn't work.. you can only imagine my disappointment!!!
Short term, I might look for an alternative for Tempo... but I've used it quite a bit in the past, and it's really a great plugin for Jira.. if only Aha! would support it..
At this time, due to your decision to not address an issue that prevents use of Aha! by users of JIRA Tempo, I cannot implement Aha! at a new employer. I hope you understand and I have implemented Aha! at a previous company and am a huge fan of your software but, I have to abandon my plans and start again with a search for a new solution due to your decision.
As we dig more into our Aha/JIRA integration this is becoming an issue for us as well.
This a major issue for our company and it effectively breaks the roadmapping process between issues moving from Aha! to JIRA for those of us that also use Tempo Timetracking. Please escalate this issue because there is no viable solution for us today. We have invested a lot of time and effort in to Aha! to work with our JIRA/Tempo setup and to find out at the very end it's not going to work is a very big deal.