Why do a template repeat a JQL query inside a branch?

[Luiz Eduardo Freitas Santos]

On an template (to send an email when an issue aproaches the due date), the JQL query is repeated again inside a branch (the loop for each Assignee). It was already executed at the begining to return the desired issues...

Why?

[John Funk · Accepted solution]

Hi Luiz - Welcome to the Atlassian Community!

Can you share the rule that you have so far? And then what's wrong with the results? 

[Luiz Eduardo Freitas Santos]

The rule is from a template - When a task is close to the due date then send an remainder email (or something like that is the text on the templates available). The JSON exported to the rule is too big to post here (too noisy).

But the logic is:

When: Scheduled (every day at X o'clock)

Then: Create a variable (somevar)

And: Do a search, a JQL expression with the 'somevar'

    For each: some smart value from the JQL resultset

        Then: Do a search, a JQL expression with the 'somevar' (AGAIN!?)

        And: Send an email with some smart value from the JQL resultset

[Bill Sheboy]

Hi @Luiz Eduardo Freitas Santos 

Would you please post images of your complete rule and the audit log details showing the rule execution?  Those may provide context for what is happening, as I suspect this is either a branching or a variable scope issue.

Kind regards,
Bill

[Luiz Eduardo Freitas Santos]

It is not an issue (apart from the lexical repetition), it works, it is Jira Software's own template... I just want to know why the JQL is repeated inside the loop branch.

[Bill Sheboy]

The reason I asked to see an image of the rule is what you describe is not possible: nested branching in automation for Jira rules.

And so I believe we are not aligned on how you are describing the rule and my understanding of it.  Seeing the rule will confirm that.

Without seeing your rule...

I hypothesize you are seeing one or more JQL conditions and instead describing them as iterations/branches.  A JQL condition can perform tests on issues to decide if the rule can proceed but it cannot supply issues for later processing.

If you instead you are asking about re-creating a variable inside of a branch, there are two possible scenarios for this...

1. There is no edit function for created variables.  Instead a variable can be created before a branch (on a single issue), the variable can be recreated inside of the branch, and then the updated variable is available after the branch.  This is a special case, because...
2. If your branch is on multiple issues, creating and using a variable inside of the branch may not work as you expect.  Branches on multiple things are executed in parallel and asynchronously.  And so each time a variable is created in such branches it is new, and thrown away after each item processes.

To learn more about branches, please look here: https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/

To learn more about conditions, please look here: https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/

[Luiz Eduardo Freitas Santos]

Yep, I think we are not in the same page, I'm posting the image of the rule, you will see that the JQL query is repeated inside a 'for each' branch.

This is the query repeat: 'duedate <= endOfDay({{numberOfDaysBeforeDueInclusion}}) AND statusCategory != done AND assignee = {{distinctAssignee}}'

I thank you for your time on this.

[Luiz Eduardo Freitas Santos]

You see.. we are already inside a for each loop that iterates through each record for the result of the first JQL query "duedate <= endOfDay({{numberOfDaysBeforeDueInclusion}}) AND statusCategory != done AND assignee != empty".

I'm new on Jira's automation and syntax, but I'm a developer... as such I consider executing such 'SQL' repetition inside a loop that already is iterating through the records as an error...

My point of view is: executing a query to retrieve all records where a field is not empty, then, executing a query for each previous record where that given field is equal to the value retrieved at that record item... that's just dumb.

[Bill Sheboy]

Thank you for that rule image. 

You noted earlier getting this rule from a template, and I believe you are using this rule from the project's templates: When a task is new due --> send email reminder.

The two different calls to Lookup Issues with similar JQL have two different purposes, helping to send each assignee one email, with only their issues.  I will explain each step of the rule to help...

1. The scheduled trigger runs once per day, with no JQL
2. A created variable defines how many days prior to due date for the checks.  This makes it easier to change the rule in the future.
3. Lookup Issues gathers any issues meeting the JQL criteria for upcoming, due issues, storing the results.  This may have multiple issues for each assignee, and so we need a way to only send one email per person
4. The branch uses the Lookup from step #3 to get each distinct assignee, not each issue in the results.  Now we can loop over them, one by one
5. A new Lookup Issues uses the same JQL from step #3, but adds a check on the assignee so we only get one person's issues
6. Now we send the email, it is only for one person

How does that help?

There is a rule feature that should help with this scenario: smart value, list filtering.  However it cannot take variable as a parameter, and so we need to call Lookup Issues twice.

[Luiz Eduardo Freitas Santos]

I understand, I just think that it could have been done in a different manner, without the need to execute queries again (same ones in essence), don't know if Jira's query can agregate or group records.

Perhaps it makes the logic simpler beeing a template, as it should.

Thank you.