Is there a way to send one email to one assignee with email body containing only assignee's issue

[vdhanorkar]

I have created one automation rule and I am trying to send a list of issues to the individual assignee through a single email but could not do that. Users are receiving multiple emails also they are receiving other's tasks details in the email body(See the second screenshot).

Is there a way where I can send a list of issues to each individual through a single email?

[Darryl Lee · Accepted solution]

After proudly showing my solution to a colleague he commented: I was just using filters + subscriptions. To which I replied...

He's exactly right. That's way easier. And the emails look much nicer.

Your filter would be something like:

assignee = currentuser() and resolution is EMPTY

https://support.atlassian.com/jira-work-management/docs/work-with-search-results/#Workingwithsearchresults-subscribeSubscribetosearchresults

[Bill Sheboy]

Yes, and...after you get the people to subscribe to the filter  :^)

[Danno · Accepted solution]

OK, I just don't get it. I'm trying to do this very thing without having to parse assignees. It's a simple Lookup search and send email using the exact text of @Darryl Lee example and my email comes back blank. I've been able to send emails before w/o any issues but now it doesn't work. This is the second automation this week I've had trouble with.

[Bill Sheboy]

Hi @Danno 

If you run your JQL manually, does it have any results:

worklogAuthor = currentUser() AND worklogDate >= startOfWeek() ORDER BY updatedDate DESC

And, who is the rule "actor"?  If it is the default of "Automation for Jira" it will likely not find any issues.  If it is "user who triggered the event" it may find them.

You could instead change the JQL to used the {{initiator.accountId}} when checking the worklogAuthor, and leave the rule actor unchanged.

Kind regards,
Bill

[Danno]

@Bill Sheboy that is the weird thing about this. The Lookup Issues action does find the correct number of issues (5). I validated it in the automation setup. My original intent was to get the number of issues a user logged time in for a given period, in this case, startOf Week(). I didn't include the rest of my automation yet because I broke it earlier when I started to set it up to email the user. When it came back with the blank email I figured I needed to back up and get that working so I moved it to the position it's in currently. As you can see it still isn't working.

I've included the rest of the automation and the audit log here to verify the original lookup worked.

[Bill Sheboy]

Please note in the audit log that the Lookup Issues returned no issues.  That is likely because the rule actor is the default of "Automation for Jira", and that is then used as the currentUser() in the JQL.

Please try changing your Lookup Issues JQL to this and run the rule again:

worklogAuthor = {{initiator.accountId}} AND worklogDate >= startOfWeek() ORDER BY updatedDate DESC

[Danno]

@Bill Sheboy The error message about returning no issues is weird because it does. Note the Log Action at the bottom of the first image. It returns the table values for the five issues that are collected by the Lookup Issues action.

I did get it to print details on the issue I used to trigger the manual trigger if I changed the smart values in the email body. I'm starting to wonder if that is my issue. I appreciate you continuing to work on this. I'm trying different approaches to the email as well. Hopefully, we'll hit on something.

OMT, your filter suggestion doesn't work. See below.

[Bill Sheboy]

What you are seeing in the last audit log entry is from writing {{worklog.timeSpent}} and {{worklog.started}} to the log.  However, my understanding is the {{worklog}} smart value is only relevant for the Work Logged Trigger: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--worklog--  I would expect the values you are seeing are undefined / not relevant to the person triggering the rule.

That JQL I provided can only work in a rule, as the rule's trigger provides the {{initiator.accountId}}  It cannot be used stand-alone with an issue search; that is what I believe you are showing.

I just ran a test with that JQL I provided, in a rule that was manually triggered, and it worked correctly.  Please trying running the rule with that JQL for the Lookup Issues to observe what happens.

[Danno]

@Bill Sheboy yes, I understand what the log action for {{worklog.timeSpent}} and {{worklog.started}} are reporting and it is correct for my original search query. I'm getting the correct data that I want to send in the email. I only wrote back regarding your search query because as you stated it doesn't work in a JQL search and because it would not validate the search in the rule itself. That said I'll go ahead and run the rule with your search and see what happens on my end. Obviously, there is more to come from these trials. 😄

[Danno]

@Bill Sheboy we are getting closer. My latest changes include your change to use {{initiator.accountId}} in the initial search. The search captures the 2 correct issues for this week in the Lookup Issues step as shown on the right of the screenshot but the Lookup Table is picking up the entire worklog for the trigger issue instead of the one worklog in the current week. It doesn't capture any data for the other issue listed. See the screen capture below.

I have also been able to get the email to send the two sets of headers but without any of the information from the issues in the original search. See below:

[Bill Sheboy]

When using Lookup Issues, try referencing the fields without an issue. prefix, like this:

{{#lookupIssues}}
  {{key}}
{{/}}

If you prefix as {{issue.key}} inside of the iterator, I would expect the results to be empty, which is what you are seeing.  The reason is once inside an iterator, nothing outside that scope (i.e., lookupIssues) is visible.

And, what is the purpose of your use of Lookup Table for this rule?

[Danno]

@Bill Sheboy thank you again for all your help. Your suggestion of dropping the "issue." from the smart values seemed to be the key to getting me where I am now. Can't thank you enough.

I have deleted the Lookup Table. I thought I needed it when I started trying to write this rule.

I now get an email that iterates through the two issues captured in the original search with the entire work log for that issue.

Now I am where this overall thread started. I suspect I will need to math it up to parse out what I need. Get the user name instead of the ID # and drop the unnecessary entries.

I don't know if there is a better resource for how to work with smart values but if you can refer me to one I would appreciate it. Knowing when to use worklogAuthor for the search and knowing when to use worklog.Author for instance.

Here is where I am now:

[Bill Sheboy]

To get the name, please try adding the displayName attribute.  The default attribute for user fields is the accountId, as that is needed for most operations.

So your value for the email, inside the lookup iterator, would be this:

- Author: {{worklog.Author.displayName}}

That would be the list of worklog author, names.

And as you noted, the worklog is itself a list of entries.  If you want to pretty-print that output a bit you can nest the {{#worklog}} some fields {{/}} inside of the lookup iterator.

If instead you want to sum-up, you could do things like this:

- Author: {{worklog.last.Author.displayName}}
- Time started: {{worklog.first.started}}
- Time spent: {{worklog.timeSpent.sum}}

Please adjust as needed for your scenario.

[Danno]

@Bill Sheboy I was pretty sure I could sort out the rest of this w/o another request for help but I am still struggling with the email.

I tried to implement your suggestion of nesting the "{{#worklog}} some fields {{/}} inside of the lookup iterator." to no avail as the email came back empty.

After reading the other posts here I thought I could test the work log entries for the start date to be >= to the start of week before adding it to the email. After battling with parenthesis and getting the correct number of rule closures, it claims to run w/o errors but my output is back to being blank. I guess I can't use a function <startOfWeek> in the #if statement. And I did change my text in the email to capitalize the Of.

[Bill Sheboy]

The date/time functions like startOfWeek() are for JQL only, and not smart values in a rule.  In a rule, you could instead try one of these to find the Monday for the current week.

• {{now.withNextDayOfWeek("MON").minusDays(7)}}
• {{now.withDayOfWeek(1)}}

Next, when you note the nesting of {{#worklog}} ... {{/}} did not work, would you please post the expression you used in your email?  Seeing that may help explain what is happening.

[Danno]

@Bill Sheboy I added the {{now.withDayOfWeek(1)}} smart value in a Log action which gets me the correct date.

I then tried using that in my Send email step with a conditional logic statement nested inside of the {{#lookupIssues}} statement as you suggested above. The audit log indicates I am close to making it work but I can't determine what I am missing from the smartvalue.

[Darryl Lee]

Ooooh, sorry to jump in here, with an "oh oh, I know, I know!", but ... I know!

Worklogs is a list, so you need to iterate through it too. Something like this:

{{#lookupissues}}
Issue: {{key}}
{{#worklog}}
{{#if(startofWeek().isBefore(started))}}
Worklog:
-- Author: {{Author.displayName}}
-- Time Started: {(started}}
-- Time Spent: {{timeSpent}}
{{/}}
{{/}}

[Bill Sheboy]

@Danno -- you appear to be missing a closing, right-parenthesis in that condition, and that is what caused the error in the log.

And thanks, @Darryl Lee -- and I believe you are missing a closing {{/}}

[Danno]

@Darryl Lee keep jumping in if you think of something. Unfortunately, that doesn't fix it. Part of your solution has already been covered by one of @Bill Sheboy 's earlier responses.

I tried it by adding the {{#worklog}} nested smart value and replaced your startOfWeek() call with the {{now.withDayOfWeek(1)}} smart value suggested by Bill and I am still getting the error

Send email

Error rendering smart-values when executing this rule:

Parameters not closed: (worklog.started.isAfter(now.withDayOfWeek(1)):

[Darryl Lee]

Ah yeah sorry, wrong function. And @Bill Sheboy 's eagle eyes caught a few problems. I think the corrected code should be:

{{#lookupIssues}}
Issue: {{key}}
{{#worklog}}
{{#if(started.isAfter(now.withDayOfWeek(1)))}}
Worklog:
-- Author: {{Author.displayName}}
-- Time Started: {(started}}
-- Time Spent: {{timeSpent}}
{{/}}
{{/}}
{{/}}

A reminder that because you're looking at the worklog inside of a list iterator, you would just use started, not worklog.started.

[Danno]

@Darryl Lee Oh my just when I thought this was on the verge of being solved I still have issues. Your version of the email code has fixed the errors I was still getting after adding the third closure (I still don't understand why) but I'll take it.

I've also noticed that I am not getting a value for this one {{now.withDayOfWeek(1)}} like I originally thought. I added a Log Action to verify this:

When I change it to the other recommendation, {{now.withNextDayOfWeek("MON").minusDays(7)}} I get a correct value:

So now if I use your code for my email I get the email with the two issue keys that are returned by the search but I'm back to it not reporting the work log information.

 

If I replace the conditional logic statement {{now.withDayOfWeek(1)}} from Bill Sheboy to {{#if(started.isAfter(now.withDayOfWeek(1)))}} I get the error again

Send email

Error rendering smart-values when executing this rule:

Parameters not closed: (started.isAfter(now.withNextDayOfWeek("MON").minusDays(7)):

This has to be one of the most frustrating coding experiences I've ever had. I shall continue to experiment with it.

Latest update: I tried to use the Log action to tease out some details. It appears that the conditional logic statement is somehow missing parenthesis again.

[Darryl Lee]

Ok, I actually tested the code, and the following works:

{{#lookupIssues}}
Issue: {{key}}
{{#worklog}}
{{#if(started.isAfter(now.minusDays(7).withNextDayOfWeek("MON").withHour(9).withMinute(0)))}}
Worklog:
-- Author: {{Author.displayName}}
-- Time Started: {{started}}
-- Time Spent: {{timeSpent}}
{{/}}
{{/}}
{{/}}

Notes:

• Bill's suggestions for how to get the start of the week were uncharacteristically wrong. I tested them by putting them in separate Audit Log actions. This is always a good idea.
• To calculate most recent Monday morning (9AM), I did ended up with this: now.minusDays(7).withNextDayOfWeek("MON").withHour(9).withMinute(0)
• I added withHour(9).withMinute(0) because it kept using my current time.
• You need three {{/}}'s because you have to close the {{#lookupIssues}} iterator AND the {{#worklog}} iterator AND the {{#if}}.

VERY IMPORTANT NOTE:

You wrote, "I'm trying to do this very thing without having to parse assignees".

I don't believe you can do this without parsing assignees. Your current JQL specifies currentUser().

So to me that means you're trying to generate a report for EVERY person who logged any work on a ticket in the past week that tells them:

• For each issue they worked on:
  • Who all (not just them) logged work on that issue.

You've been testing this with a Manual Trigger, so it works (or will work) for YOU.

The problem is, if you try to run this on a Scheduled Trigger, it will only run for a single user (the Automation Actor, so possibly nobody).

If I'm right, then like I said, you want this to run for anybody who did logged work this week. If that's the case, then going back to my previous solution here, YOU MUST parse assignees.

LMK if that's not your use case, and we can regroup. But as I was solving the technical details (which is fun), I remembered to step back and look at the bigger picture (which Bill is really good at).

[Danno]

Woot! Thank you both @Darryl Lee and @Bill Sheboy for putting up with me and having the persistence to follow it through. See the result below. I will still need to test this for other users but I expect it should work.

As of right now, the last set of corrections Darryl provided made it work. I think I created my own set of issues when it appears I assumed there was a <isBefore> function. I also am trying to figure out why using the Create Variable action didn't carry through in my email script plus one or two other mysteries I can't resolve for now because I am tired of this problem and need a break from it.

I am still wondering where I might find more reference material on how to implement smart values correctly. I asked two of my software engineers if they recognized it to no avail. Whatever became of the original automation team that was bought out by Atlassian. I think it would be great idea to get them to weigh in on my request.

Now to answer the other items you referenced.

Yes, you are correct in that I will need to parse the <worklog.Author> from the returned list of worklog entries in case there is an outlier of an entry by someone other than the initiator of the rule within the timeframe of the #if query.

My initial JQL uses the rule initiator instead of the current user which was a suggestion of Bill's to try to ensure we were getting the correct issues.

For now, I want this to be a manually run rule. We have implemented a new timekeeping app for accounting reasons and it prompted me to go down this path after looking at doing a JQL filter subscription and finding I couldn't get what I wanted. I was looking for a way for the users (people logging work in Jira) to easily get a quick report of their Week-To-Date hours logged.

So, to summarize, for now, I am wanting the email to go to the rule initiator with just the worklog entries created by them since the start of the week, not all of the entries.

Yes, I was planning to try to expand it to run automatically on a Fri. at noon so they would get an email with the sum of the worklog for that week. That email might end up reporting the time spent by a custom field for a chargeable Job Code in our accounting system but that is for another day.

[Bill Sheboy]

Awesome!

And regarding this in your post...

I also am trying to figure out why using the Create Variable action didn't carry through in my email script plus one or two other mysteries I can't resolve for now because I am tired of this problem and need a break from it.

My hypothesis is you are trying to use a created variable inside of an iterator.  At this time, iterators can only "see" from the scope of the iterator and downward.  They cannot see anything from the outside.

Does that match what you are observing in your rule?

[Danno]

Yes, I think you confirmed what I suspected. I created the variable to debug using one of the versions of "Find the first of the week" that you suggested. The created variable was returning the data correctly so I thought I could call it in the iterator.

Thanks again for your help.

[Darryl Lee]

Yeah, you got what you needed @Danno and thanks for the context. That always helps!

Ok, so yeah, sounds like you've got a handle on what you need moving forward. 

Unfortunately I fear that your idea of additionally filtering the Worklog by author is going to run into the same issue @Bill Sheboy just detailed above: the {{initiator}} smart value will not be accessible from within the {{#worklog}} iterator so you won't be able to do what should be simple:

{{#if(equals(worklog.Authors, initiator)}}

^^ This will not work.

Maybe there's some hackery possible via converting it to a string via join() and then splitting/replacing text? That's Bill's speciality though. :-}

[Darryl Lee]

It would help if you can screenshot your entire rule.

If you are using a JQL condition then you need to take the email action *outside* of that condition because it's executing for *every* issue it finds.

Not sure why it's showing other assignee's issue unless there's a problem with your JQL.

So yeah, seeing the whole rule would let us better help you.

[Darryl Lee]

Sorry, I hadn't had enough coffee this morning. :-}

Upon re-reading your question, I'm guessing that you are doing a lookup of issues where Due Date IS EMPTY. 

So yeah, I think the problem is that unless you constrain the query to a single assignee (and then you'd have to create rules for every assignee), then it's going to (apparently) mail every assignee the list of everyone's issues.

[vdhanorkar]

@Darryl Lee Thanks for looking into this, here is the screenshot as you requested.

[vdhanorkar]

@Darryl Lee I found a similar ticket https://codebarrel.atlassian.net/browse/AUT-1975,

but I am confused about whether this problem got solved or still exists, as per the task description it is not possible to send an email to one assignee with an email body containing only the assignee's issue. 

Could you please confirm? If it is got resolved then please tell me the solution.

[Darryl Lee]

Yeah, I don't think they should've closed AUT-1975 as a duplicate because while AUT-684, AUT-285, and AUT-105 are related they are not the same.

So yes, as I suspected, your query will always return a list with multiple assignees, and so there's no mechanism to iterate through each assignee and send a list with only their issues.

Hum, if you could iterate through the list of assignees, you could probably use filters to do something like:

{{#allassignees}}
  {{#lookupissues}}
     {{#if(assignee.accountId == allassignees.this.accountId)}}
        * {{key}} | {{summary}} | {{assignee.displayName}} | {{url}}
     {{/}}
  {{/}}
{{/}}

But the problem is 1) I don't know how to get that list of assignees out of Jira, 2) I don't think you can have nested lists in Automation. :-/

[Darryl Lee]

Oh man! I'm getting close! Got the list of assignees and can iterate through it with Advanced branching, accessing {{lookupIssues.assignee.distinct}} like so (this is the "For each" section that shows up in the full rule at the bottom:

But the problem then is my "filter" can't access the thisassignee variable within {{#lookupissues}} for the email body. I unsuccessfully tried:

{{#lookupIssues}}
{{#if(assignee.accountId == thisassignee.accountId)}}* {{key}} | {{summary}} | {{assignee.displayName}} | {{url}}{{/}}
{{/}}

(which gave each assignee a blank email)

and

{{#lookupIssues}}
{{#if(assignee.accountId == {{thisassignee.accountId}})}}* {{key}} | {{summary}} | {{assignee.displayName}} | {{url}}{{/}}
{{/}}

which failed with: 

Error rendering smart-values when executing this rule:

Here's what I'm working with. Any thoughts, @Bill Sheboy?

[Darryl Lee]

Ah, think you solved this previously, @Bill Sheboy by adding another JQL query for each assignee. Clever. https://community.atlassian.com/t5/Jira-questions/Smart-Value-Filtering-Comparing-Two-Lists/qaq-p/1959275

For option #3, you could use lookup issues and advanced branching to then notify the people...or send yourself n-emails (one for each person).  Here is an example rule to do this:

Let me give that a hack.

[Bill Sheboy]

Yes, and...

I believe the requestor asked the same question in this other thread, where I also answered: https://community.atlassian.com/t5/Automation-questions/Re-Re-1-Notification-per-assignee-via-Automation-on-Jira/qaq-p/2092384/comment-id/4502#M4502

[Darryl Lee]

Success!

Full rule: 

And details on the new second Lookup:

So there you have it. BTW, I corrected your original mail body @vdhanorkar because you had {{issue.summary}} when you just need {{summary}}.

[vdhanorkar]

Thanks @Darryl Lee , it works to me, thanks for looking in to it.

[Paul Stahlke]

@Darryl Lee I tried to implement this using your latest screenshots. While the email itself looks perfect and does to the correct assignee, it sends it as many times as there are issues for the assignee. It's as though it's iterating through all the assignees in the first lookup rather than just the "distinct" assignees. I am running in Jira Cloud. Any ideas?

[Paul Stahlke]

Disregard! I was using the Schedule trigger and have the habit of applying a JQL search there as well, so it was iterating through that. Removed it, and it works beautifully!

[Dan Tombs]

Hi @vdhanorkar

I think the alternative would still lead to running a multiple send email and lookup action etc. But branching out and specifying individual users could also work

[Benajmin Kun]

@vdhanorkar @Bill Sheboy @Darryl Lee @Dan Tombs Hi guys need your help, I tried to build this automation but I get an empty assignee.displayName 

[Bill Sheboy]

Hi @Benajmin Kun 

Please check your smart values in send email, as you have a typo in {{assignee.displayName}}

And...you seem to reference an issue's fields outside of the Lookup Issues iterator; before it specifically.  Try using {{thisassignee.displayName}} or {{lookupIssues.first.assignee.displayName}} for that one.

Kind regards,
Bill