Notify assignee if no comment is made for 7 days

Question

Hi.

I have already created an automation rule that will send a reminder to the assignee if a comment has not been added to the Jira issue since 7 days.

There are two scenarios a) and b)

a) Comment is present: When the last comment was added 7 days ago

b) Comment is not present: Jira Issue has no comments ever. And its been 7 days when the issue was moved to Sprint. What I have done here is when the issue moves to the Sprint, I set a custom field 10015  (Start Date) equal to that day when it was moved to Sprint in order to calculate the difference in days.

The above rule works fine and sends email in both scenarios successfully, but I am not getting the expected result in cases, when a Jira Issue has sub-tasks.

When the Jira issue has a sub-task, the developers comment on the individual sub-task and not the parent task. What I actually want is: Iterate through all Jira items in the opensprint(with or without sub-tasks), and send email reminder to assignee if none of the sub-tasks has been commented since last 7 days.

What is happening now: Based on my JQL, I iterate through all the items in the opensprint (only the parent issues) and if the parent issue has not been commented, then it sends email reminder. This works totally fine if I do not consider the sub-tasks logic.

If I expand my JQL (by checking sub-tasks as well), then each Jira issue (parent and sub-tasks) gets counted individually and do not give the expected result in case of Jira issue with sub-tasks. Suppose if I have 5 issues and each issue has 4 sub-tasks and condition of not commenting for 7 days gets satisfied, then there will be 20 email reminders instead of just 5 (which I actually want)

Note: I don't want to use Script Runner or any other add-ons in order to achieve the results because I am not sure whether in my Company that will be allowed or not.

Bill Sheboy · Answer

Oh...now I see what's happening: this is a branching and created variable effect.

---------

First thing, there is only a "create variable" and no "update variable".  More about why that is important in a minute.

Branches on one-and-only-one thing (e.g., branch on parent, branch on current issue, etc.) essentially are run in-line, as if the branch was not present.

All other branches (e.g. for sub-tasks, branch on JQL, etc.) are run in parallel and asynchronously.  There is no guarantee of when they will finish, up to the last step of the entire rule.  And...other than edits, what happens in the branch for each loop goes out of scope and vanishes.

---------

Putting these ideas together and looking at the rule image, you are trying to update the variable "flag" in the branch on many things, but that is impossible with the way branches work today.

When you want to gather information to decide something for multiple issues, it is better to gather the issues using the Lookup Issues action with JQL, and then treat them as a set.  ( For the special case of subtasks, I believe you could directly access them with {{issue.subtasks}} )

Keshav_nphcv9 · Answer

Thanks @Bill Sheboy for the response. I am going with case #1. I tried to do what you and @Patricia Francezi_iDev_ suggested, but I am facing issues in them.

Below are the steps;

a) create global variable 'flag' and set it to 1

b) loop as many times as count of sub-tasks (say 4)

if last comment < 5 mins, set 'flag' = 0 (will change to 7 days during actual implementation)

loop ends before step d)

d) if 'flag' = 1 (denotes no sub-task had a recent comment)- send email to assignee of parent issue

else 'flag' = 0 (denotes one or other sub-tasks had a recent comment)- don't send email reminder

--------------------------------------------------------------------------------------

In log action, I see couple of issues

1. When using for loop, the execution of steps is not sequential

2. I loose the value of variable 'flag' when it comes out of loop even though it has been defined at the start.

Can you please help me with the steps?

--------------------------------------------------------------------

Screenshots

Bill Sheboy · Answer

Hi @Keshav

With your addition of sub-tasks to this "send reminders" use case, one challenge is built-in JQL does not support returning both the parent issues and their subtasks with one query.

Your possible solution approaches depend on what outcome you want:

* send a reminder to the assignee for each individual issue
* send one reminder to each assignee, containing all of their issues

For case #1, use your original rule and JQL to only find the issues (not the subtasks).  Check the issue and send a notification.  Then branch over any subtasks to repeat the checks in a loop to send more notifications.  I believe this is what @Patricia Francezi_iDev_ suggested.

For case #2, this might be possible if you gather all the issues, and then walk them by distinct assignees in an advanced branch.  Disclosure: I have not tried this scenario, so you will need to experiment a bit.

* remove the JQL from the scheduled trigger
* use a lookup issues action with your original JQL to gather the keys of all of the issues
* create a variable to save some JQL for future use; let's name that varIssuesJQL

key IN ( {{#lookupIssues}}{{key}},{{/}} )
 OR parent IN ( {{#lookupIssues}}{{key}},{{/}} )

* use that saved JQL to find all of the relevant issues with a second lookup issues action
* advanced branch over the distinct assignees, {{lookupIssues.assignee.distinct}}* use a third lookup issues action, adding the loop variable to the saved JQL above

Kind regards,
Bill