@atlassian this is a product request that I will follow up with our account rep. I've run into minor issues with order of operations where actions occur not in the order they're listed, but by some race condition. For example, I have an edit field rule immediately followed by audit log. I'm finding that the field is actually edited (confirmed by viewing the issue), yet the audit log isn't reporting that field. The issue is not what I wrote to the audit log, take my word that this is an order of operations problem.
I have experienced other examples where I need to actually change my rule because the running of operations makes the rule ineffective. My request is for a pause/sleep operation where the API can get caught up before enacting on rules placed further down the list.
If I am missing something and there is a way to work around order of operations would love for someone to share.
First thing, I am just a user offering input, and not an Atlassian employee. With that out of the way...
I did not find any suggestions in the public backlog for this idea, and you may add one if you wish.
Update: I did find these two suggestions in the Code Barrel backlog (now part of Atlassian)
And, based upon your rule design there definitely could be timing issues. For example, anything inside of a branch which covers more than one issue is executed asynchronously and thus there is no guarantee of when that processing finishes.
Perhaps if you post an image of your rule and audit log, and explain what you expect versus what you observe, that will give the community some context to offer suggestions. Thanks!
Thanks for the finds @Bill Sheboy
It would seem that both focus on the crux of the issue. Yeah I'm wondering if branching on the rule (to run on 'current issue') would help in this case. Ultimately I don't know how the backend works so it's a bit of a crapshoot. The edit "Amount" field is a simple calculation from a couple of other smart values (not advanced edits).
This is the most basic rule where I've seen it fail due to timing. I've attempted more complicated if/else blocks with handfuls of steps (running only on the current issue), so without a concrete understanding it doesn't make sense to dive into those.
Even if there is a workaround the sleep/pause/delay would still make things a lot simpler.
Thanks for the rule image. Do you mean that when you edit the Amount field within a rule, and then log it to the audit log, the updated value is not logged? If so, that functions as documented.
The rule loads issue data at the moment of trigger, and when you change fields they are updated *in cloud storage*, however the loaded values have not changed. For your example, you would need to use a Re-fetch action after the edit to then log the changes. So not a timing issue for this example.
And...there are known timing issues related to triggers, particularly Issue Created, where all of the data is not yet available when the rule fires. The work-around for that is to add a Re-fetch action after the trigger, which slows down the rule and re-loads the issue before further processing.
Looks like you've got this figured out but just to fill in the blanks a bit:
In this scenario, it is not a timing issue but a performance optimisation. Any changes that you make to the issue during execution are not reflected automatically for subsequent steps. This would require a round-trip to Jira so could slow your rule down unecessarily - so we don't do it.
As you've discovered, adding the re-fetch forces Automation to go back to Jira and get the updated values only if you need them to be there.
I would recommend using 2 rules instead and use this post about calling rules from another rule. https://community.atlassian.com/t5/Jira-Software-questions/Automation-how-to-calling-rules-from-another-rule/qaq-p/1347348
I'll mark Bill's answer as the right approach since there isn't a clear cut answer and those two tickets do seem to address the core of the problem.
Would still appreciate a functional albeit temporary solution if someone is familiar with how to work around this issue given the current toolset.
Hello Community! We thoroughly enjoyed this just-for-fun conversation in the Jira Admin Group about what it's like to be a Jira Admin. For #JiraJuly, our talented designers created these graphics t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events