Automation - Linking to a linked work item's own linked work items

[Thomas Brennan]

I feel this should be simple but I can't get my head around a working solution. 

Currently we link work items, sometimes through automation, within a project. What I want is an automation running that, once a work item has been linked, will then link and other links in those work items to that first work item.

For example, currently we have an automation within a project that matches a specific field with any other items and then links those to it. What I would want is for it to then find if those linked cases have any other links and also link these in to the trigger item.

[Marc - Devoteam]

Hi @Thomas Brennan 

This is not simple and could/will lead to loops.

Example.

You have issue A and link this to B and B has links to C and D, but D is also already linked to B, then you will get a loop.

But if you have an extra custom field that you specify as in you example, you could try to use a lookup and then branch over the found items and link them to the trigger issue.

You might even need to create other variables and use web request to the API to get all the information or even make put requests to link the items togethe.

[Bill Sheboy]

Hi @Thomas Brennan -- Welcome to the Atlassian Community!

Adding to the suggestions from @Marc - Devoteam ...

Without seeing the exact scenario you are trying to solve and your current rule, it may be difficult to make suggestions on how to proceed.

Specifically, what problem are you trying to solve with this type of linking?

Until we know those...

What you describe is often very risky to implement with automation rules.  Work item linking has no limit or referential integrity checking, and so:

• nothing prevents cross-linking work items, leading to cycles back to the start
• there are no limits on the number of links
• some link types are not detected by the built-in rule features (because they are implemented in code, such as with JPD "delivery tickets")

Thus a rule using JQL or linking information could greatly exceed the capacity of automation service limits by count, endless loops, or the amount of processing per hour.

Kind regards,
Bill

[Thomas Brennan]

Here is one of our current automations for our repairs project. Currently when a work item is created it requires the serial number of the returning item. This links any other work items matching the serial number field so we can see how many times it has been in before and for what reasons. Our returned items are never in more than 4 times before being decommissioned. However, if one of our repairs has had a memory issue then we have to reserialise it which the new serial number would go in to the "Updated Serial Number" field. So if that item comes back in again it will only bring up the last time it was returned for repair. I would like for it to also see that what it has linked to also has previous links, and link those to the latest work item. 

[Marc - Devoteam]

Hi @Thomas Brennan 

Still as mentioned by @Bill Sheboy and me, you know you can't have more then 4 issues linked!

But this stil won't resolve the issue that someone can just add links to one of the 4 issues and that it can resulting loops, still can run to the automation limits.

As mentioned, you can't limit linking.

You could create specific link types, to try and prevent the issues touched, but still that still can result in issues if people start to use this links.

Using specific work items and specific link types, would be my best suggestion, that would limit it as much as possible.

Rather still limits and loops can occur.

[Thomas Brennan]

Within this project someone can't just link issues, that is stopped by the permissions. If an item can only come back 4 times. That's 3 links on each of the 4 work items. 

I'm just wondering if this is possible and how.

[Bill Sheboy]

Thanks for the additional information, @Thomas Brennan 

First, your rule appears to access work items in multiple projects.  Thus, the rule scope must be global or multiple-project to access those.  This can be done by a Product Admin in the global automation area.

Next, for the rule you show there are a few things to improve:

• Smart values are name, spacing, and case-sensitive.  The one for the trigger issue is: {{triggerIssue}}
• When comparing the short text, custom fields in JQL, wrap the values in quotation marks
• The JQL is missing parenthesis around the the tests on the serial numbers.  As written, that will potentially match work items in other projects.
• You probably do not want to add links when they already exist, so add a clause to the JQL to exclude them with the linkedIssues() function

Putting those together, please try this:

project IN (RMA, BR)
 AND (
         "serial number[short text]" ~ "{{triggerIssue.customfield_10034}}"
      OR "Updated Serial Number[Short text]" ~ "{{triggerIssue.customfield_10034}}"
      )
 AND issue NOT IN linkedIssues("{{triggerIssue.key}}")
 ORDER BY Key ASC

I recommend testing that with an example work item in an search outside the rule to confirm it works as you expect.

[Taliah15]

That sounds like a smart way to keep all related work items connected seamlessly! Automating the linking of links will definitely save time and create a more comprehensive network of work items. It might require a recursive or multi-step automation to pull in those extra links—worth exploring!