Pull Linked Issue name into custom field via Automation (Jira Cloud)

[Apryl Harris]

Hi,

I've seen a few similar articles but they don't seem to fit my use case...I am trying to pull in the NAME(s) of linked issues into a custom field, Name of Linked Issue(s) (labels type), id = customfield_11600.

Is this possible? If so, I need the automation.

Help please!

Thank you!

[Bill Sheboy]

Hi @Apryl Harris 

What does "Name of a Linked Issue" mean to you?  Is this the Summary field?

And, would you please clarify what you are trying to accomplish? 

For example, do you want to...

• When an issue is linked to another issue
• Copy the custom field "Name of Linked Issues" from one issue to another

If so, which is the "source" issue to copy from, and to which issue do you want to update?  The way your rule is written, it will do nothing other than copy the value from the trigger issue back to itself.

Or...do you mean something else?

Kind regards,
Bill

[Apryl Harris]

@Bill Sheboy - thanks for responding. My rule is wrong but I don't know how to correct it.

I'm trying to accomplish the below:

• When an issue is linked to another issue,
• Copy the linked issue's Summary to the custom field = "Name of Linked Issues" in the other issue 
  • Name of Linked Issues is a labels type field.
    • For this to work, should the custom field be text?
• then I plan use the filter results gadget on a Jira dashboard to list the stories with the Name of Linked Issues and the Linked Issues fields

Thanks for your help):

[Bill Sheboy]

Thanks for that information.  A few follow-up questions before suggesting some specific approaches:

Would you ever expect there to be multiple issues linked, such as one-to-many issues?

If you do have many-to-many issue links, what would that look like in that custom field?  For example, a long string of the summaries.

What would you expect to happen to the custom field when a link is removed?

[Apryl Harris]

1. Would you ever expect there to be multiple issues linked, such as one-to-many issues?

answer = Yes

2. If you do have many-to-many issue links, what would that look like in that custom field?  For example, a long string of the summaries.

answer = a lot of labels

3. What would you expect to happen to the custom field when a link is removed?

answer = the label should be removed if the link is removed

Thanks for thinking about these use cases and asking the questions.

[Bill Sheboy]

Thanks for that information, Apryl.  Short answer: this may not be easily possible with an automation rule.

Would you please describe the problem you are trying to solve by reporting on that information?  That may reveal another solution approach.

For your requested approach...the problem is the many-to-many links.  As a result, such rules rarely work as expected.  Here is an example rule and why this may not work.

1. Trigger on issue linked
2. Use a branch on JQL using on the trigger issue's change log to walk over all of the previously linked issues.  This is needed as some links may have been removed.
   • use a Lookup Issues Action with JQL to find the linked issues
   • update the custom field with Summary values from the Lookup Issues
3. Use a branch on JQL using on the trigger issue's change log to walk over all of the currently linked issues.  This is needed as some links may have been added.
   • use a Lookup Issues Action with JQL to find the linked issues
   • update the custom field with Summary values from the Lookup Issues
4. finally we can update the trigger issue, using another Lookup Issue Action on the currently linked issues
5. update the trigger issue's custom field with Summary values from the Lookup Issues

One problem is caused by a feature of rules: branches on multiple issues run in parallel and asynchronously.  And so the same issue could be repeatedly updated, leading to problems.

A complicated work-around is to use 2 rules: one to process the trigger issue and tell all current and prior linked issues to update themselves, and a second rule for them to update themselves for the custom field.