I'm looking to add an action if and only if it is the first time the status has changed from one status to the next in the workflow and ignore if it is subsequent times. Suggestions?
Thanks
Hi @JD.Lobue
I am assuming you want to add an action for the transition from Status A -> Status B. Additionally, perform the action only if the issue hasn't been in Status B before.
You could try using the JQL validator 'status was not in (Status B)'.
Let me know if that helps :)
Regards,
Bhanu
Hello @JD.Lobue
As @Bhanu KN has mentioned, JQL syntax will be
project = XXX and status was not "In Progress"
(you can ignore the project = XXXX part in your rule)
So if you have a trigger of "status changed", then you first check if issue status = "statusB" and if so, you do another If condition -> JQL -> status was not "statusB"
Then you do your steps.
Please review below link for more details:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @JD.Lobue
Yes, and...to this suggestion:
If you use, or have ever used in the past, any team-managed projects in your Jira site: the status changed operators for JQL may not work as expected. Here is the defect for that symptom: https://jira.atlassian.com/browse/JRACLOUD-78387
The work-around is to use the id values of the statuses rather than their names.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe not a proper solution in your situation, but in other cases it could be better to change the workflow to allow only one-way transition from status X to status Y so that Automation will be triggered only when Issue transitioned from X to Y, for ex.:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you want to check for the first time, "was not in (X)" does not help you since:
The "WAS" operator is used to find issues that currently have, or previously had, the specified value for the specified field. (Note: This operator can be used with the Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only.)
So if you put a jql with "was not in (X)", since the status IS X, it wont work as it is.
I managed this with this jql "status was not in (X) BEFORE -1m" checking if it was not in that status before 1 minute, and since you have this in the transition itself, you should be able to make it work.
See image for my example with "In Progress"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Please review the other posts in this thread, particularly if you have ever (or currently do) have any team-managed projects in your site. The WAS operator does not work consistently if there are / were team-managed projects, even when the workaround of using the status id values in the JQL is used. The defects for this symptom in the public Jira backlog are marked as either timed-out or "won't fix".
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi JD,
You might try creating a custom field - just a radio button with a Yes/No or a Checklist with just Yes. Then when the issue moves to that status for the first time, set the value to use. You should be able to hide the custom field from the screen.
Then you can check with your automation as to whether that field has a value of Yes or not.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @JD.Lobue
Another solution is, you will have to store an "indicator" in a custom field or entity property, whenever an issue has transitioned from a particular status or whatever your criteria is.
And your rule will check for this value/indicator (can be anything) and if it exists, it does nothing, if it does not, your rule continues with your action steps and finally you update this field for future.
And because this approach is go forward, whatever method (custom field or entity property) you choose, you have to bulk update that for all historical issues so they dont get triggered unnecessarily.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.