Automation: Iterating through worklogs (by using #) and accessing {{triggerIssue}} + cond. logic

[Tomislav Tobijas]

Hi,

We have stumbled upon a specific use case. Let's say there are two issues - APP-247 and APP-248 and User A is assigned to issue APP-248 (and this issue has Start date set). While working on APP-248, the user has also logged some work on APP-247. I/the client would like to get a report displaying only those worklogs from APP-247 that have started after the start date of APP-248 (see image below - in this example, we would only like to write down worklogs "WL #3" and "WL #4"). The 'report' could actually only be text field on APP-248 issue that contains this information.

We've started to build up an automation for this and this is what we have so far...

First we have a branch that finds all issues where the person who was assigned to a trigger issue also logged time after the "Start date" of an trigger issue (this works fine 👌).

Next, for each filtered issue, we go through the worklogs by using {{#issue.worklog}} smart value. The problem occurs when we try to fetch {{triggerIssue.Start date}} smart value within this iteration - it seems that system cannot 'handle' that - meaning you can only get values from iterated worklog (e.g., author, started date...) but nothing out of that scope.

I've tried logging the following phrase:

{{#issue.worklog}}started: {{started}}; triggerIssue.Start date: {{triggerIssue.Start date}}; IF: {{if(started.isAfter(triggerIssue.Start date), "true")}}{{/}} 

but as you can see in the screenshot below, outside the iteration smart value properly shows trigger issue date, while inside the iteration it does not.

So the question is - is this not supported by Jira?

Another question is regarding the IF statement inside the iteration - is that something that's supported? As you can see from the phrase above, I've tried placing {{if(started.isAfter(triggerIssue.Start date), "true")}} smart value inside the iteration (I even tried replacing trigger issue date with fixed date), but it doesn't seem to work.

We've also tried some combinations with placing IF statement in the main iteration smart value - something like {{#if(issue.worklog.started.isAfter(triggerIssue.Start date))}} ... {{/}} but that also didn't work.

Any help would be appreciated 🙌

Cheers,
Tom

[Bill Sheboy · Accepted solution]

Hi @Tomislav Tobijas 

This is a known limitation of automation rule, list iterators: they can only access data from the scope of the iterator, and lower.  They cannot "see" other issue fields, created variables, branch variables, etc.  In a few different posts, I have read Atlassian engineers tried to fix this limitation but were unsuccessful.

Depending upon your Jira version, a complicated work-around is to use in-line, text matching functions instead.  The idea is:

• expand the list into a created variable (or custom field) in a known format as text with delimiters (e.g., named varCompleteList),
• use split() and match() to parse out the desired records, and
• use the resulting records, converting the types from text, as needed.

The "trick" to make this work is to build the dynamic, match expression first, such as in a created variable or custom field.  That may be used as :

{{varCompleteList.split(",").match(varSearchExpression)}}

Another work-around is to perform such actions outside of the rule, by creating a service in another programming language, passing the issue data or keys, and then calling that service with the Send Web Request action.

Regarding using the isAfter() use in a list filter, I have observed inconsistent results even when using a literal value.  Perhaps instead use the gt() function and format the dates to allow comparison, such as yyyy-MM-dd.

Kind regards,
Bill

[Tomislav Tobijas]

Cheers @Bill Sheboy !

Thought so that there's the limitation you mentioned. I see this workaround as something that may be too complex to build (at least with automation), so ScriptRunner might be better way forward here.

Also, thanks for the insight about isAfter() function!

Best regards,
Tom