The more that I use Automation, the more often I'm pushing its boundaries via smart values. These are pretty powerful and open many options, but are at times challenging to test. It would be great if Atlassian provided a tool with two fields and a result. * Target Issue - This would be the issue that the smart values should reference in the test. * JQL - This would be where you type your JQL with smart values. I imagine this tool serving a simple but valuable function of letting you see what your JQL would return if you ran it against the target issue. As it is, I often have to configure a manual trigger for my automations to test them while I build out my JQL queries to ensure I'm getting the intended results. This requires a lot of back and forth and waiting simply to verify some JQL.

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; } } }

It would be great to have a tool that allows quick testing of JQL with smart values.

Brock Jolet_wkfaaa

The more that I use Automation, the more often I'm pushing its boundaries via smart values. These are pretty powerful and open many options, but are at times challenging to test.

It would be great if Atlassian provided a tool with two fields and a result.

Target Issue - This would be the issue that the smart values should reference in the test.
JQL - This would be where you type your JQL with smart values.

I imagine this tool serving a simple but valuable function of letting you see what your JQL would return if you ran it against the target issue.

As it is, I often have to configure a manual trigger for my automations to test them while I build out my JQL queries to ensure I'm getting the intended results. This requires a lot of back and forth and waiting simply to verify some JQL.

Accepted answers

All comments

Darryl Lee

@Brock Jolet - YES. I pretty much always end up starting with Manual Trigger rules for this reason.

I like your idea, but I think it'd be better if they just updated the existing "Validate query" functionality they already have for JQL fields.

They've added things like "Insert account id" and "Resolve users". What they need is to add your suggested "Target Issue" here:

And then yeah, once that is set, it should populate any smart values from that issue when you click Validate query (which is currently grayed out because of the smart values.

What do you think @Dilani Kahawala and @Charlie Gavey? Can we get a feature request for this?

Arnd Layer

I often use a Webhooks trigger during development of my automations. I found it easier to tgrigger using command line, postman or even Apple shortcuts than triggering manually from an issue.

Darryl Lee

OH MAN, I love this idea. In fact, it gives me some ideas on how to automate (using shell scripts) manually running several automation rules that have to happen in sequence (where I could not figure out how to cleanly chain them together).

Darryl Lee

Oh hey so tonight I was reading @Esther Strom's excellent article on Automating the creation of a Confluence page linked to a Jira ticket and noticed something about the Send Web Request action:

It includes a validator! So Atlassian already has some code in Automations that is able to lookup an arbitrary Jira issue and use that to populate smart values:

Screen Shot 2022-12-13 at 11.40.16 PM.png

Arnd Layer

I see one major problem for chaining multiple automation rules together in a sequence. Whatever triggers the webhook will receive a HTTP status 200 response when the request has been successfully received. But the rule execution is asynchronous. There is no indicator that the rule has been successfully run.

You could build a HTTP request action into your rule to signal this. This would then require that the machine controlling the sequence is running a web server and accessible from the Atlassian Cloud.

I'd be interested if you find a remedy for that.

Darryl Lee

Oh yeah, I just did a bunch of sleep commands. :-}

This isn't for anything in production where I'd need confirmation the rule ran successfully, but yes, that would definitely complicate things.

My use case was:

Clone of a bunch of issues from a "template project"
Transition some of those issues to "Selected for Development"
Transition some other issues to "In Progress"

(So mainly I'm just watching stuff move around on the Issues page or Board to know when each step is done, and steps 2 and 3 still don't work reliably, so I need to keep an eye on things.)

But most importantly I think the Webhooks trigger would be great for *TESTING* rules, as you pointed out. Not having to navigate through Automation -> Rule executions -> Run would be nice.

On the OTHER hand, I can usually leave that "test bug" open somewhere and click [Run] whenever I need to. At any rate, always good to have another option!

Esther Strom

Hey, @Darryl Lee - I wasn't aware that the validator could be used in the execution of the rule. I've always thought it was just there for testing - i.e. you give it a specific ticket number and it does a dummy run on the rule and gives you the return values of whatever your webhook is so you can see what the return structure looks like.

Can you actually use that value in further rule steps?

ETA: doh! I should have read the entire thread instead of just the bit that mentioned me 😁 It's my first day back after almost 3 weeks of vacation... the validator is intended for exactly the purpose you indicated.