I'm trying to create an automation that will transition all issues in a version upon a manual trigger. For context, my organization will add to the Fix versions field when an issue's changes are merged to the version's branch. When we're preparing to release a version, we first do regression testing. I would like to use what's in the Fix versions field to transition all issues in a version from Status 1 to Status 2.
I've tried the following automation, but it's not working for me. The automation just won't run.
1. Manual trigger with user input - text field "Version Name", variable name is {{testingVersion.Name}}
2. Branch rule - For: JQL ({{userInputs.{{testingVersion.Name}}}} IN {{issue.fixVersions.Name}})
a. Condition - status equals Status 1
b. Transition issue - destination is Status 2
Could anyone please help me to figure out why this is not working? Or perhaps there is a better approach?
Big thanks to @Bill Sheboy for helping me out. There were a few issues.
1. The Variable Name in the trigger's input field had curly brackets around it, but it should not.
2. I was expecting the trigger issue to be transitioned, but the rule was set up so that only related issues were transitioned, and there were no related issues while testing.
You should be able to accomplish this with something similar to what you're already trying though I'm not quite sure what you're trying to accomplish with the variable:
fixVersion IN (YOURVERSION) AND status = status1
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for your help @Mark Segall
I tried this, and I'm still running into the same issue where the automation just won't run.
The variable is meant to capture the name of the version which is being tested. We might have multiple versions that are unreleased, and I want this automation to run only for issues in a particular version. The Version Name input needs to capture the version that we want this automation to run for.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Adding to Mark's answer:
For a question like this, please include images of your complete rule and the audit log details showing the rule execution. Those will provide context for the community to offer suggestions.
Until we see those...
What do you mean by "the automation just won't run"?
Does your version name contain spaces or other non-alphanumeric characters? If so, please try modifying the JQL Mark suggested as follows, narrowing the rule scope and handling the characters in the version name:
project = {{triggerIssue.project.key}}
AND fixVersion IN ("{{userInputs.testingVersion}}")
AND status = status1
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 @Bill Sheboy
Here are those images. I hope they help.
I meant "the automation just won't run" as in - I would try to trigger the automation from an issue, and instead of running, a pop-up appeared that basically said "Oops, we can't run this automation." I've fiddled with it a bit more, and it's running now, but I can't say for sure what I changed to get it to run.
In this sample project, the versions do have a space, so I added the parentheses and quotes. I tried double quotes and single quotes. In the audit log screenshot, you can see now what's causing errors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for that information. Would you also please post an image of your rule trigger?
I suspect the problem is the Variable Name in the trigger's input fields has curly brackets around it...but it should not. Instead it should be just be testingVersion, like this
And after that is fixed, I believe you need to use double-quotes, not single-quotes, in the JQL.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You were right. I had the curly brackets in the variable name, so I removed those, and the rule seems to be running fine now. However, no actions were performed when I would have expected it to transition an issue.
Here's a screenshot of the test issues I'm working with. I ran the rule from SSP-12, put Version 2.0 as the testingVersion input, and expected it to transition, but it didn't. The audit log says no related issues were found for the branch JQL. I thought that SSP-12 would be found.
project = {{triggerIssue.project.key}} AND fixVersion IN ("{{userInputs.testingVersion}}") AND status = Building
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm...would you please post an image of the audit log details as that may indicate something, including the exact JQL it tried to use when the rule ran.
You can also write that dynamically-generated JQL to the audit log so you can test it manually (in an issue search) to learn what is happening.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The audit log isn't showing the JQL it used to run the rule.
I changed the automation - removed the branch rule, removed the transition action, added add value to the log: the same JQL I have been using. Here's what I got.
Then I took that JQL and did an issue search and got this.
It seems like everything should work properly. I know that in the workflow there are some conditions limiting what users can do a transition. A while back I ran into a different problem where an automation was unable to transition an issue, and I found out that I needed to include in the conditions that atlassian-addons-admin can do it. I already changed the transition here to include that.
That condition is set so that All conditions apply. I tried Any too and still no luck.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Would you also post the audit log from before you removed the branch and the rule did not find anything? That will show us the complete flow. Thanks!
By the way...another thing to try: rules can sometimes get "glitched" by too many edit/save/publish cycles and so they stop working. There is something in the rule editor which seems to cause this. The work-around/test for that problem is to disable your current rule and re-create it from scratch, and then test.
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.
In that branch, do you have this option checked:
"Only include issues that have changed since the last time this rule executed"
If so, please uncheck it and the issues will be returned to process.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Bill Sheboy
That box has been unchecked. I tried running the rule with that option checked and got this instead:
I really appreciate all of your help. It's so strange to me that this isn't working.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For your scenario, I believe you want that checkbox unchecked...so all issues are found.
Did you see my earlier comment about rules getting "glitched" by too many edits/publishes? Have you tried to disable this rule, recreate it from scratch, and see how that helps?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did see that. I tried to make a fresh one earlier and didn't have any luck. I just tried again and still none :-(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Let's put these two tests together to learn if we are missing something obvious:
After your trigger, and before the branch, add a write to the audit log with the JQL you are about to use in the branch. That will confirm, in context, what the branch is about to use. Then run your rule and post an image of the audit log details.
And...would you post an image of the rule details section, showing the actor and scope of the rule?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, so I put a second issue into Building and the same version, and the automation worked for the other issue, but not the issue that I triggered the rule from!
Here are pictures:
This is a good development. I could just add another transition action into this rule so that the trigger issue is transitioned as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.