Tempo would be much more valuable if we could allow tickets within an Epic to inherit the Account of the Epic.
The problem with not having this functionality is that every single ticket needs someone to select this field and we will end up missing things. We have thousands of tickets. If we miss tickets then our CapEx/OpEx reporting will be inaccurate. We also cannot expect that individual user's will know which account to select when submitting their time log.
| Tempo Products | Tempo Accounts |
| Tempo Platform | Cloud |
As an update, due to a licensing issue with JIRA, we lost our premium functionality which removes automation, killing the alternative solutions....
Very disappointing that this was raised nearly 6 years ago with no movement as such a basic accounting issue. Perhaps we need to use something else for time logging.
This is critical for large/complex projects/teams. Currently I have automation setup, but this doesn't not allow exceptions. This solution would be far simpler as by default all tickets would take the parent account, unless specifically set.
I don't know if this helps, but we integrated ScriptRunner and build these scripts for tickets to inherit parent's account field
This _should_ also be possible by adding a post-function to the Create transition of the respective Story-level workflows in company-managed projects.
Hi everyone, this feature would be extremely helpful for us on our Data-Center instance. Currently it is also pretty confusing to train members with the current state because:
It is working for Issue -> Sub-Issue
It is working the Teams field correctly.
Hi everyone,
As pointed out in the previous comment, it's possible to solve this use case with Automation for Jira, although that solution might not be viable for everyone. For those with Jira Cloud Premium or limited usage, an Automation for Jira rule like the one documented here can work for you.
At the moment we do not have an exact ETA for this being built into the product.
Regards,
Hlynur Johnsen
Group Product Manager
Yes I agree, this is critical for us too as we currently need to use automation which will breach our automation limits in jira