Jira Automation sending resume email of all watched jira with due date near or past

[albanoandrea]

Hello, 

we would like to create an automation to send every day an email with the resueme status:

• list of all the Jira assigned with due date near or past
• list of all the Jira watched  with due date near or past

For the first point we could use the automation in the library named When a task is near due → send email reminder.

So, for the second point we have tried to modify the automation to get the dinstinct watchers in the For each: smart value step 

{{lookupIssues.watchers.distinct}}
{{lookupIssues.watchers.split(",")}}

We did several attempt trying to look at the documentation and at other post, but there seems to be no way to get dinsinct watchers and then send a single mail to all the user with the list of Jiras.

Probably we need to completely change the automation principle, do anyone have an idea on how we could do it?

[Bill Sheboy]

Hi @albanoandrea 

For a question like this, please post images of your complete rule and the audit log details showing the rule execution.  Those will provide context for the community to offer suggestions.  Thanks!

Until we see those...

I am guessing you are using an advanced branch to iterate over the watchers:

• Each watchers field in your issues is a list, and distinct alone could produce the distinct combination of selected watchers across the issues. 
• Instead please try first to merge all of the watchers into a single list, and then use distinct. 
• Within your branch you can then use lookup issues to select the issues for that watcher.

Kind regards,
Bill

[albanoandrea]

Thank you @Bill Sheboy ,

any idea on how I could create the list of all watchers?

[Bill Sheboy]

You can do this in two steps, as I do not believe this is possible in one step...

• action: create variable, to save the arrays of watchers for each issue
  • name: varWatcherList
  • smart value: {{lookupIssues.watchers}}
• action: create variable, to convert the arrays to a list and then get the distinct users
  • name: varMergedWatcherList
  • smart value: {{varWatcherList.remove("[").remove("]").remove(" ").split(",").distinct}}

That last line removes the square brackets from the arrays, and then splits the text field on commas...which converts it to a list.  Now the distinct function can be used.

Once you have tested to confirm this works as you expect, you can use the smart value expression (or the varMergedWatcherList variable split again on commas) as the source for your Watcher, advanced branch.

[albanoandrea]

Thank you @Bill Sheboy
I think that now I'm very near, I just need last thing that I don't understand.

Going step by step, in the first phase I'm creating the variables as you suggested.

After each step I'm sending an email to me to verify that the variables are ok.

Since there are 3 jiras with 2 different watcher only, the variable varWatcherList is an array with 3 elements.

After the second step the 2 watcher are correctly extracted.

In the second part of the jira I want to dinstict the watcher.

For every watcher I send to me this email, but the emailAddress and displayName is empty 

Here the result for the 2 watchers.

So, what I miss is to extract the email address because the last step is this:

And emailAddress is always empty.

[Bill Sheboy]

Yes, that is correct, as you only have the account id and not the other fields.  (The default field for a Watcher is apparently accountId, and not the entire user object).

When I pause and re-read your original question about Watchers, I do not think this is possible in the way you asked with a rule.  I wonder: what problem are you trying to solve by pushing information to the watchers...when watchers are just observing for changes?

Next, a few work-arounds:

• Create a saved filter and ask your watchers to subscribe to it individually, and so a person (i.e., watcher) will get one email per schedule.

watcher = currentUser()
 AND statusCategory != Done
 AND duedate <= endOfDay(2d)

• Create an automation rule, on a scheduled trigger with that JQL, and re-mention each watcher in a comment.  This will send an email to each watcher for each issue.  That may be quite noisy for users, up to 100 emails per run.  (Lookup Issues is limited to 100 issues.)
• You can force this to work, by calling the REST API with a web request for each watcher's accountId in the branch, and so get the email address and display name.  I expect a rule like this will be both slow and eventually fail as it exceeds the allowable runtime/SLAs for a rule in your license level.

Finally, an explanation of why this probably cannot work in a rule: 

The reason is that inside the scope of rules, my experimentation shows Watchers behaves both like a list and an array.  And Watchers cannot be used directly as a source to an advanced branch.  To get at the other fields you would need to parse out all of the data for use later, like this:

{{#lookupIssues.watchers}}{{accountId}}|{{emailAddress}}|{{displayName}},{{/}}

But...if you try that, you will find Watchers does not work as expected (like a list); instead it puts all of the accountId values together, and then the email addresses, and so forth. 

myAcountId,yourAccountId|myEmail,yourEmail|myName,yourName

That will not help when you need to use distinct later, and to access the individual pieces.

Sorry I could not be of more help on this one.

[albanoandrea]

Hi @Bill Sheboy 

thank you again for your time.

The purpose of this rule are multiple:

• if I'm not the assignee, but I have an interest on the task to be done on time, when that mail comes I can push the assignee if he is just ignoring it (this unfortunately happens very often just because the assignee think that no one care about the task).
• if I'm the responsible and I know that the priority has changed when I see the task in the list and I understand that the due date can be delayed I can just change it inform the assignee. 
• we have some generic tasks, where to be completed, we need to do several micro tasks from several people and the effort of creating a sub task for every micro task is not reasonable (e.g. we have tasks that should have 20 sub task each completable in less than 5 minutes), so, since multi assignee is not allowed, we use to tag people involved in the task and add them in the watching list.

Anyway, thanks again for the deep explanation, we will think about a possibile alternate solution or just give up if no one else can provide a different proposal.

[Bill Sheboy]

How about using that filter (or others) with a shared Jira dashboard?  People could pull (rather than a pushed email) when they want information about their assigned items, or watched, or etc.

[albanoandrea]

Well, that is actually what we wanted to avoid. 

[albanoandrea]

Hi @Bill Sheboy
so here some more details.

This is the starting rule:

Where For each: Smart Value is

And I'me trying to substitute it with something like

And then

[albanoandrea]

In particular the result of this rule is that I get several email for every different group of watchers:

if there is at least a Jira with only me as watchers in the related email I get the right list of Jira near to due date.
Here what I get when there is 1 jira with just me watching and another with another watcher: