Automation for inheritance of issuelinks field with "relates to" value only

[David Exner]

Hello community!
We can not achieve an inheritance of linked issues with "relates to" relation only from parent to child once a child is created.

We tried using smart values but could not find a way how to express it to the automation to get it to work.

You can see a draft of a rather general approach to inheriting any of the linked issues in the attached screenshot.

Could you please help us how to achieve it? 

Thank you!

[Bill Sheboy · Accepted solution]

Hi @David Exner 

You cannot directly set the issuelinks field only, as shown in your rule image.  The reason is both issues which are linked are updated during the linking operation.  And, I believe the REST API only supports linking two issues, and not one issue to many others.  (Although I have not tested that.)

Instead consider finding the issue keys for the issues to link-to, and then using an Advanced Branch iterate over the keys and use the Link Issues action.

Kind regards,
Bill

[David Exner]

Thank you @Bill Sheboy ! We will give a try and let you know.

[David Exner]

Uff, so I am not sure whether I can achieve what we need to since it resulted in the successful run of the rule but the new issue was not assigned with any "Relates to" links while the parent has them. Any ideas, please?

[Bill Sheboy]

I am confused as what that rule is trying to do.  For example, that created variable will produce a text string that looks like below, and then try to link that to another issue:

SEP, SEP, SEP = "Strategic Initiatives"

Would you please explain / confirm what problem this rule is trying to solve?  It seems what you initially described is:

• GIVEN an epic exists which has linked issues of type "relates to"
• WHEN an issue is created which is a child of that epic
• THEN link the same linked "relates to" issues to the new child issue

[David Exner]

Ok, here it is:

1. Trigger: issue created
2. Check whether this newly created issue has any parent or epic.
3. If so, check whether there are not any "Relates to" issues linked to the newly created issue.
4. To look up all issues, that are linked to the parent of the newly created issue.
5. That should be a variable with all the issues from lookup belonging to the project "Strategic Initiatives" <- After your comment, I realized that I mixed up two things together, I guess I should rather look up these issues again.
6. Once the belonging issues are found link them to the newly created issue. 

Thank you for your help @Bill Sheboy !

[Bill Sheboy]

Thanks for clarifying, and one final question:

Are all of these issues in one project, or is the project "Strategic Initiatives" a separate one from where the target issues for this rule exist?  That is important because if the projects are separate, the rule scope will need to be multiple-project (or global) and your Jira site admin will need to change the rules scope.

For now, I'll assume they are in one project.  Your rule was pretty close but needed some adjustments; let's simplify it a bit...

• trigger: issue created
• action: re-fetch issue.  Due to potential timing problems, it is a good idea to always add this action immediately after the issue created trigger.
• condition: there is an epic parent
• branch: on JQL to get the issues linked to the parent with a type of "relates to" using JQL.  The JQL you already wrote should help with this.  Because no processing will proceed unless issues are found, no additional conditions are needed.
  • action: link issue to the trigger issue with {{triggerIssue.key}}

If the issues are in multiple projects, and the linked ones should only be in the "Strategic Initiatives" project, you would only need to change the branch JQL to include that.

[David Exner]

The rule is, for now, set up only for newly created issues of only one project (SEP)- we want to test-run it there. We just need to link these new issues to the related Jira issue from the different project = STIN ("Strategic initiatives"), which is currently linked only to their epic/parent.

We were also thinking about creating a new "STIN" field storing the key of the STIN Jira issue, but we wanted to avoid the need to add one more custom field if we can already use the existing linking feature.

Anyway, if we find out that the linking is not a good idea, we will want to be able to read the linked STIN Jira issue of the parent and then save its key to the "STIN" field of the children.

I hope it is clear :)))

[David Exner]

Hmm, so I probably found an issue with:
issue in linkedissues({{triggerIssue.parent.key}}, "relates to")

If I use: issue in ({{triggerIssue.parent.key}}, "relates to")

The parent is recognized by the automation even though it results in error because of "relates to" which makes sense:

But if I use: issue in linkedissues({{triggerIssue.parent.key}}, "relates to")

The parent is not even recognized (1st "Lookup issues"):

But if I use the search it in issues with the parent "TEST-45" mentioned directly in the query, it works and I can find the related Jira issue (STIN-445):
issue in linkedissues(TEST-45, "relates to")

It seems like smart values can not be used for linkedissues(). 

I also simplified the rule:

[Bill Sheboy]

Your lookup issues action has the curly brackets in the wrong place in the JQL.  Please try this:

issue IN linkedIssues({{triggerIssue.parent.key}}, "relates to")

[David Exner]

My bad, it was done by mistake while playing with it, thanks. Anyway, after correcting it, the result is still the same:

Should I refer differently to the issue and not by using a key?

[Bill Sheboy]

Just to confirm, you want those linked issues which are only in the STIN project, correct?

If so, please change the JQL for the first lookup issues action to this:

project = STIN AND issue IN linkedIssues({{triggerIssue.parent.key}}, "relates to")

And then the second lookup is not needed.

[David Exner]

Good point, thanks!

Anyway, It is still not working.

The linked STIN-445 issue ("relates to") to the parent of the newly created issue is still not captured. 

But in issues, the JQL is working fine:

I am not gonna lie, I am now a bit desperate :))) 

Is not the referencing {{triggerIssue.parent.key}} wrong? 

Thank you for your continuous support! It is much appreciated. 

[Bill Sheboy]

Earlier I noted rule scope, and for a rule to access issues in multiple projects, the rule must be global or multi-project in scope.

Is your rule project-scope only?

If so, your Jira site admin will need to help change the scope.

[David Exner]

You were right, Bill, my bad. Thank you for your help!

Btw, since we realized that this approach is not the best (we can end up having hundreds of issues linked to the STIN issue), we would like to use the current automation for listing the STINs linked to the parent and then filling their key(s) to the new custom text field (single line) "STIN".

We tried to change the automation to this one below, instead of using "Link issue" we added  "Edit issue" +  we used a smart value "{{lookupissues.key}}" as a new field value:

Despite having the status "Success" the value was not written to the "STIN" field. Do we miss any data type transformation? Or what else could go wrong, please?

[David Exner]

Btw, I have found that ".format(“#”)" is used for transforming the output to a string as per the link below, but it did not help either. 

{{lookupIssues.key.format(“#”)}}

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Jiraautomationactions-Editissue

[Bill Sheboy]

That format() function should not be needed as the following produces a comma-separated list of keys:

{{lookupIssues.key}}

You can force that to text with this:

{{lookupIssues.key.join(", ")}}

Also, try writing the number of items to the log after the lookup to confirm what was found:

lookup found issue count: {{lookupIssues.size|0}}

And also...based on what you are showing, none of those Re-fetch issue actions should be needed in your rule.

[David Exner]

This one helped us:

{{lookupIssues.key.join(", ")}}

We removed re-fetch actions too. 

Thanks again, Bill!

[David Exner]