Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Want to have an automated email send information about a linked(parent issue), double nested

Brandon Garrett July 17, 2024

Hey, 

This seems like a complicated one, at least to me:  I currently have an automation that fires off and works great, but would like it to do additional reporting.  Basically, I want it to be able to push out a smart value reading of the parent of the parent.

Here is the basic setup:
-We have a Board (Called Projects) that is the parent board for another board where the projects are broken up (The "child" board is called Agency)
-When Epics are created in the Project board a secondary issue is created and linked to them on the Agency board.

-The Agency board represents the work that is actually being done whereas the project board just tracks the completion of the overarching project.
-Because of this we have notifications sent out to our sales team when chunks of work get completed on the Agency board.  Right now, the Automation correctly Identifies the parent of the subtask in the agency board when sending the email.

**What I want to do**
I want the current automation that sends off to ALSO identify the Parent from the Project board that is linked to the Agency board.  The link classification is currently parent.

Here is what I have for my current automation (maybe its as simple as my smart values being wrong):
https://imgur.com/a/THZryuG

The highlighted ones output nothing.
Here is the email I receive:
https://imgur.com/a/DERH8Cc

And finally, here is the ticket in question to prove that it does have a parent linked. 

https://imgur.com/a/wDgIiIi

BTW, yes, I do have the rule set to apply to BOTH of the boards in question, it exists in global automation rather than being attached to one board.

 

This whole thing may be a simple syntax error.  The automation works great aside from not being able to show the parent of parent.

Thanks in advance for your help!

1 answer

1 accepted

3 votes
Answer accepted
Trudy Claspill
Community Champion
July 17, 2024

Hello @Brandon Garrett 

The first problem with your email is your reference to {{createdIssue}}. That is used to refer to an issue that is created within the executing Automation rule. Your rule is not creating any issues.

Second, your references to {{issue.parent}} in the email would all be attempting to reference the parent of your sub-task's parent issue. In the branch you have change the focus of the rule to the parent of the sub-task. So within the branch {{issue}} will be referring to the parent of the sub-task.

Third, in your email references to {{issue.parent.epic}} doesn't get POCBP-744 for two reasons.

  • First, in that context {{issue}} is referring to the parent issue of the sub-task. If you wanted to refer to the sub-task's parent issue's Epic at that point in the rule you would use simply {{issue.parent}}. 
  • However, the second reason the reference wouldn't work is because you have used generic issue linking to connect the sub-task's parent to the related Epic. The reference you have used will work only if the Parent field in the sub-task's parent is updated to the key (POCBP-744) of the Epic. This also impacts your reference {{triggerIssue.parent.epic.summary}}

Is there a specific reason you are using generic issue linking rather than updating the Parent field?

 

The best way to fix this would be 

1. Update the Parent field of the sub-task's parent issue to POCBP-744

2. To reference the subtask in the email use {{triggerIssue}}

3. To reference the parent of the sub-task in the email use {{issue}}

4. To reference POCBP-744 (the "grandparent" of the sub-task) in the email use {{issue.parent}}

Brandon Garrett July 17, 2024

Trudy, Thank you so much for your reply.  Gives me lots to think about.  Your second bullet point gets to the core of the issue.  I had figured our linking from grandparent to parent was problematic in the past and it makes more sense why, now that I am reading your feedback.  I will have to do some work in revamping our linkages across the two boards and test your proposed solution.

I will report back when I have had a chance to do so.

Thanks again!

Brandon Garrett July 17, 2024

Noticing a comment you made on a previous thread:
"If you are using Team Managed projects, those don't allow you to specify parent/child relationships between issues in different projects."
Since we are on a Team Managed Project for both of these boards in question, that sounds like it will not be possible to make the actual parent child relationships that you are suggesting in your solution.

Is that correct?

If I was on a company managed project, it sounds like this would be possible, yes?

Thanks

Trudy Claspill
Community Champion
July 17, 2024

Correct - if either one of the projects is Team Managed, the parent Epic and child issue must be in the same project.

Correct - if both projects where Company Managed, then the parent Epic and child issue can be in different projects.

However, if you are considering trying to change to Company Managed projects, that comes with its own set of challenges.

So, let us assume you are not going to change your projects and we are therefore forced to work with the generic linking to identify the parent Epic.

There are some clarifying questions I need to ask.

  1. Would you ever have a more than one "is child of" link on an issue?
    1. What would you want to do in that case?
  2.  What if there is no "is child of" link at all? What would you want to do in that case?
  3. What information are you trying to add to the email? Explain in words using the following references:
    1. Subtask refers to the issue that triggered the rule.
    2. Parent refers to the parent of the subtask
    3. Epic refers to the issue Parent is linked to by "is child of"
Like Brandon Garrett likes this
Brandon Garrett July 17, 2024

Thanks again for a thoughtful and helpful response.
1) Yes, we do have multiple Epics linked to Parents (that are on the other board)
    1) In that case, I would want all Epics to be included in the email notification.
2) If there is no Epic attached to the Parent, it would be fine for the email to just have a blank space in there.
3) In this situation
  1) Subtask refers to type of data
  2) Parent refers to Source of Data
   3) Epic refers to the Client we are doing the data gathering/analysis for
So the end result of the email would say something like 
"Salary Data(subtask) for Data Source(Parent) has been completed for the following Clients (Epic)"

Hope that helps clarify.  I included a screenshot to illustrate an example for #1
https://imgur.com/a/bdRZVYu

In this example the automation would fire off when subtask POCBA 1632 was marked as complete, and the email would include the information about the Parent, POCBA-1631 and all of the Epics, POCBP-30 etc.

I did verify that I cannot make the connection between the POCBA and POCBP board as per the company vs. team managed feedback.

Thanks again!

Trudy Claspill
Community Champion
July 17, 2024

Since your Parent and Epic issues exist in different projects you will have to create this rule from the Global Automations screen. You will have to set the Scope to Multiple Projects and you will have to set Projects to all the projects that could be involved.

You may want to add a Condition after the Trigger to proceed only if Project = POCBA, so that the rule will proceed only if the subtask was in the expected project.

A rule like this should work. (Ignore the issue types I've specified. Use the values you are already using.)

Screenshot 2024-07-17 at 4.48.34 PM.png

In the above I am using a Lookup Issues action with a JQL statement to get all the Epics that are linked by the "is child of" link to the parent of the subtask that triggered the rule. Here are some reference relevant to that:

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues

https://support.atlassian.com/jira-software-cloud/docs/jql-functions/#linkedIssues--

 

Screenshot 2024-07-17 at 4.48.59 PM.png

In the above there are three sections to the email content.

In section 1 you print information from the subtask. Use {{triggerIssue}} to reference that issue and include any field you want to print from that issue. Of course you need a separate smart value for each field.

In section 2 you print information about the subtask's parent. Use {{issue}} to reference that issue.

In section 3 you are printing information about the Epics linked to Parent. These were obtained in the Lookup Issues action and are contained in a list object referenced by {{lookupIssues}}. Using this syntax

{{#lookupIssues}}

{{/}}

...tells the system that you want to print information for each issue in the lookupIssues list.

In between those two lines you put smart values naming just the fields that you want to print. So you would say {{key}} to print the issue key, {{Summary}} to print the issue Summary, and so on. If you wanted to print the issue key and summary for each linked epic then you could use:

 

{{#lookupIssues}}
{{key}}: {{Summary}}
{{/}}

 

Brandon Garrett July 17, 2024

Trudy,

Absolutely brilliant.  Thank you for the response yet again.  Everything is working aside from the lookup issues function.

I am using the same example as the picture in my previous response. Here is the error I get in the audit log: 
https://imgur.com/a/mNndvCj

I have confirmed those two numbers are the project ID of the correct boards.

I think the syntax of my lookup issues function matches yours, so I am a bit unsure as to what the error means.

issue in linkedissues("{{issue.key}}", "is child of")

The whole rule: 
https://imgur.com/a/VqB9GeC

 

I appreciate the linked resources as the syntax for jql and lookups has not been easy for me to figure out.

Everything else works great!

Trudy Claspill
Community Champion
July 17, 2024

You need to use the text you see in the Linked Issue section that shows the relationship between the Parent and the Epic - "child of"

Screenshot 2024-07-17 at 10.05.26 PM.png

Like Brandon Garrett likes this
Brandon Garrett July 18, 2024

Trudy,

It works!  You are amazing.  Thank you so much for your thorough and quick help!

Like Trudy Claspill likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events