nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Similar automation rule not working

john.monteith

I have an interesting issue, I have the following automation rule:

A04 rule.PNG

This rule performs as expected. Here is audit log of latest run:

A04 audit log.PNG

I then have this rule which was copied from the above rule and the only thing changed was the destination status in the first step. Destination status is valid and was selected using the drop-down menu.

A05 rule.PNG

However, this rule does not work

A05 audit log.PNG

Since there is nothing different about the two rules other than step 1 and that is working, I don't understand why the edit issue steps have a problem. Literally a copy of a working rule.

Accepted answers

All comments

Bharat Kalia

@john.monteith - Would you mind checking on the "Transition" screens for both the transitions and see if the fields you are trying to edit are present on the transition screen(for the second rule transition). Maybe that's the issue...I haven't tested this out but just my 2 cents.

Thanks,

Bharat

john.monteith

The transition is a valid transition:

A05 transitions.PNG

john.monteith

There are no transition screens for any of these status changes. The issues are simply changing status

Bharat Kalia

yes @john.monteith , but can you check the transition screen? That pops up when you move to implementation. Is the field is there on that screen?

Bill Sheboy

Hi @john.monteith

When a rule action edits an issue, that updates the data stored in the cloud, but does not update the in-memory data for the issue in the rule. This is by design when there are cases to observe the original data.

When you want the issue updates to be available, add the Re-fetch Issue action after an update: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Re-fetch-issue-data

However, that would not be needed for your rule if you update both fields using a single Edit Issue action.

Kind regards,
Bill

john.monteith

Thanks Bill, as I said in my post, the rule that is "misbehaving" is a copy of a rule that works as expected, so there are zero differences other than the trigger in step 1. The audit logs show a problem in the edit issues section of one rule but not in the other and it is literally the exact same commands.

Bill Sheboy

Please show images for both of the complete Edit Issue actions. Again, I recommend combining these into one action.

Until we see those, here are some follow-up questions:

Are those fields which failed custom fields that can be set manually by a person for issues, such as the trigger issue?
How is the issue transitioned which triggers this rule: manually by a person or by another automation rule?
Are there any workflow transitions which also update fields in the issue?
What is the scope of the rule: single-project, multiple-project, or global?
- When the rule is other than single-scope, the rule could be using the incorrect, custom field ID internally...even if the rule was copied from another rule which appears to work.
Who is the rule actor: the default Automation for Jira, or some other user?
- If the actor is a different user, does that actor have permission to edit the issue?

john.monteith

I combined both edit issues into one action, still has the same error, here is screenshot.
Trigger is manual.
No
Single project
Default Automation by Jira

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud