ARE YOU SURE? Using Inputs with Manual Trigger to confirm actions

[#1]

Recently a user wrote a Python script to add a comment to all issues that met certain criteria in a JQL query. But she wanted to run it as a service account.

It seemed like a more secure approach would be to instead create an Automation Rule that could be manually triggered (by a group with just this user).

The rule was simple enough, but she asked if there could be a confirmation screen because selecting an rule from the Automation menu triggers it immediately. Additionally, the menu does not close, meaning there's a real possibility you could accidentally run the automation twice (which happened to me while testing).

Using the feature to Prompt for input when this rule is triggered allows us to put up a nice confirmation dialogue that allows the user to choose Yes and then Submit.

We get the added benefit that the Automation menu closes when the dialogue appears.

Here's what the rule looks like. Pretty simple, but useful!

[Rune Rasmussen]

I don't know why I haven't thought of this myself but I will absolutely be stealing this idea going forward.
Very nice work.

[Tomislav Tobijas]

Hah yes! We do the same thing when it comes to manual triggers. Started using this method a year or so ago and got positive feedback on the popup/confirmation panel.

[Bill Sheboy]

Hi @Darryl Lee !

Thanks for the article and tip to add more error-proofing to manually triggered rules.

And, as a reminder for the example rule you show...

Rules which supply a work item with the trigger, such as Manually Triggered, automagically exclude that specific work item from branches on JQL.  That is, they add this to the JQL behind the scenes:

AND key != {{triggerIssue.key}}

This is likely another form of error-proofing, built into the engine to prevent accidental endless loops, and is not described in the documentation.

Thus when a customer triggered the rule from a work item they wanted included in the actions, they will not see it processed, may think something went wrong, and run the rule again!  Additional steps are needed to help this case, to individually process the trigger one after first testing it with a JQL condition...perhaps after the JQL branch, or before within a current work item branch.

Kind regards,
Bill

[Darryl Lee]

Hey thanks @Bill Sheboy!

Yeah, so in my initial testing, probably because I had checked the Prevent duplicates by only adding this comment once to a particular work item checkbox for the Comment action, I could've sworn that my rule was failing to trigger because Jira was adding: 

AND key = {{triggerIssue.key}}

I think I had run into something similar before and my thinking was that because Manual Triggers can only be run while viewing a particular issue, the implication is that any rule MUST relate to that issue.

And so any JQL query would have the behind the scenes JQL added that ensures that issues are related to the Trigger Issue, since the instructions for Branch rule / related work items say:

Please select which related work item you would like to perform actions against. Learn more about Branch rule / related work items,

(Emphasis mine.)

More specifically, here is the description for JQL:

Huh: "JQL search for the work item that triggered this rule". 

In fact I was so sure this was what was preventing my rule from updating any issues except for the one I triggered it from that met the JQL query, that I asked some Champions and @Trudy Claspill suggested I use a Lookup Issues action and then reference it in a For: JQL block with:

key in {{lookupIssues}}

Which worked as expected (pulling in all issues including the one it was triggered from).

[But this also begs the question, shouldn't it technically be {{lookupIssues.keys}}? (It appears Automation/JQL accepts sloppy variable typing, sigh. And I'm not even a programmer!! What is this, Perl!? :-)]

As it turns out  {{lookupIssues}} comes in handy for a little email "report" I sent after the comments were added, so I went with it, but because it was bugging me, I went back to just using For: JQL, making sure to leave the dupe prevention checkbox unchecked, and lo and behold it worked.

All this is to say, gosh, it sure would be nice if Atlassian actually documented the expected behavior of JQL as it relates to {{triggerIssue}}.

@Bill Sheboy you or I must've discussed this in some previous questions/articles. Did anyone from Atlassian or Code Barrel ever weigh in with an "unofficial" answer?

[Darryl Lee]

Ah, Google to the rescue.

[Voiceover]: "Previously on"

• Jira Automation - trigger issue not showing in JQL branch 

I guess I could just do some testing. Bleh.

[Darryl Lee]

As I'm putting together a test, I realize another factor is this checkbox in the For: JQL branch:

• Only include work items that have changed since the last time this rule executed

Yup, that would definitely exclude issues during a second run of a rule. Duh.

Welp, as usual though, @Bill Sheboy is 100% correct, and indeed, I tested multiple triggers of the same rule from issues that would have been included in the JQL.

These issues were excluded from the branch actions.

And when I tested Lookup Work Items as suggested by @Trudy Claspill I got similar results. (Triggering issue was excluded.)

Drat. Guess I'll either need to tell the user NOT to trigger it from a ticket that would be included, OR try to build around the edge case that she does.

Ugh, I don't want to add an additional check AND have an overly complex email report that uses Conditions to check if the Trigger Issue needs to be included.

So I'll just add some guidance in my handy-dandy input prompt:

This must be run from an issue that does not contain a Project-Codename label. Confirm "Yes" to continue.

[Bill Sheboy]

Hi @Darryl Lee 

My apologies if I caused any spin, and thanks for confirming my reminder on the branching behavior.  I was only trying to help for the specific example rule you showed :^)

And another FYI on what you noted for {{lookupIssues}} providing a list of keys to a JQL expression...

In my experience, smart values which have structure (i.e., multiple attributes) always have a default attribute.  The default is used when no specific attribute is selected, but one attribute was expected.  For example, with a user smart value such as {{issue.assignee}} the default is the accountId, making it the same as {{issue.assignee.accountId}}.  For an issue, that is the key.  And because {{lookupIssues}} is a list of issues, the result is:

• return the list of keys, and
• use the implied join(", ") to concatenate them into a text string

Please note my "one attribute was expected" qualifier.  When an object is expected instead, everything is preserved.  This may be seen with the Create Lookup Table action, where if a row value is set to a {{lookupIssues}} result, it preserves everything!  This is a handy way to have multiple lookup results in a rule.

Have a good one, and keep up those great articles!

[Darryl Lee]

Hey @Bill Sheboy!

Actually it was a good exercise because I actually found that my testing was wrong, and my user might have ended up running into the issue of the Trigger Issue not getting the expected comment.

That is a neat trick about "default attributes" and a clever use these structured smart values in Lookup Tables.

BTW, to close the loop re: the exclusion that Automation automagically adds to For: JQL branches, this was definitively proved by an error message I got when I forgot the parentheses around {{lookupIssues}} in my query:

key in {{lookupIssues}}

The error I got was:

SIM-1: "(key in TEAM-4, TA-1, SIM-2, SIM-1) AND (key != SIM-1)" - Error in the JQL Query: Expecting ')' but got ','. (line 1, character 15)

Which indicates that yes, I forgot parentheses around my list of keys, but ALSO, that it is excluding SIM-1 (the trigger issue) with:

AND (key != SIM-1)

Just as you described.

For the record, the query I ended up using (which works, except for the excluded issue), is:

key in ({{lookupIssues}})