How do i update the labels with the linked issue key?

[danish_khatri]

When a customer creates a ticket in Jira Service Desk, a clone gets created in the Jira software project which basically help us to communicate and provide updates to customer, now what i am trying to achieve is to show my Jira software project key in the customer service desk view using label.

For e.g.

ABCs-123 (test ticket) --> created by customer using Jira service desk 

ABC-2456 (test ticket) --> clone created in my Jira software project 

Now in the customer service desk view they should be able to see the clone ticket no i.e., ABC-2456 using label field.

Issue - When the rule is run it shows successfully run but label field is somehow not getting updated, How can i achieve this?

Note: the value you see below is manually updated and not using automation

 

[danish_khatri · Accepted solution]

Hi @Trudy Claspill & @Bill Sheboy

Finally found the problem and now it is correctly updating the linked issue key in labels.

Issue: Trigger was the problem, since this rule trigger was set to "when work item is created" and i had other rule as well where it creates clone of my service desk ticket in Jira software project also had same trigger it was not able to catch the value and update it.

Now i just have to find an efficient way of triggering the ticket from my Jira Software Project by enabling the rule at global level with both the projects because my team and other users don't have access to internal Service desk dashboard.

Thank you both of you for all the suggestion and helping me fixing this rule.

Best Regards,

Danish

[Trudy Claspill]

Hello @danish_khatri 

What is the Scope of the rule you have created? That information is on the Rule Details page.

When sharing a rule execution Audit Log, please make sure you click on all the ">" characters on the right to reveal all the details of the messages in the log.

Which of the issue creations, ABCs or ABC, are you expecting to trigger the rule?

How are the ABCs and ABC issue related to each other? Do you created an Issue Link between them?

How are you creating the ABC issue. Is that being created by another rule? If so, please provide screen images of that rule also.

The way the rule is written the Edit action is executed against the same issue that triggers the rule.

If the rule is triggered by the ABC issue then the rule has to have some method to identify the ABCs issue. And then the rule has to change its focus to that issue so it can execute the Edit action against it.

Also if these issues are in different projects then the current logic would require that the rule scope be Multiple Projects and name both the ABC and ABC,s project in the scope.

[danish_khatri]

Hi @Trudy Claspill

The rule is created to run in Jira service desk project.

Sure but there is nothing much in the audit log other than it says "executed successfully".

So when ABCs are created in Jira Service Desk project and clone (ABC) is created in Jira Software Project then it should update the ticket no of the Jira software project item in labels of Jira service desk ticket as you can see from my screenshot.

They are both are automatically linked via "Clones" & "Is Cloned By".

Yeah i thought as well but since i am just updating the ticket no of Jira software project(ABC) in labels of Jira Service Desk(ABCs) it should use the linked issue feature and fetch ticket no from there.

[Trudy Claspill]

Hello @danish_khatri 

Thank you for that additional information.

How and when exactly is the clone issue in ABC created, relative to when the ABCs issue is created?

Your rule for the JSM project is triggered by creation of the JSM (ABCs) issue. If the process to create the clone ABC issue has not completed already and the link between the ABCs and ABC issue been established, then your attempt to get information about the linked issues for ABCs may not be finding any information.

[danish_khatri]

Hi @Trudy Claspill

Yes, ABC (clone) is created when the user the submits the request in Service Desk which creates ABCs (original ticket) and it automatically creates a link between them both (clones & is cloned by).

Then what action would be recommended to use and update the label? transition or something else?

Thanks,

Danish

[Trudy Claspill]

Hello @danish_khatri 

I reviewed your last reply (where you included images) again and I see that in the image you added the note "Clone created in Jira Software Project using another automation rule".

That would be part of your problem then.

Your rule to set the label to the linked issue key is triggered by creation of the JSM issue. It is highly probably that the rule that creates the Clone issue has not completed before this rule to set the label has been triggered. So there is no linked issue to retrieve yet.

You could check that by adding a condition to this rule prior to trying to set the label

But that will only edit the label if, by chance, the automation rule that creates the clone issue has completed.

In the scenarios where the clone process has not completed you would need a separate rule to get the label updated.

I recommend instead that you amend the automation rule that is creating the clone issue so that it will also update the labels of the JSM issue. This separate rule to update the JSM issue labels would then be unnecessary.

If you show us that other rule we can advise you on how to amend it.

[Clara Belin-Brosseau_Elements]

Hi @danish_khatri

If you're looking to automatically update the labels of an issue with the key of a linked issue, Jira Automation is one option, but it has some limitations when it comes to field formatting, multiple links, or scalability across projects.

I just wanted to suggest an alternative to Automation with our app Elements Copy & Sync that lets you customize issue fields during the cloning or synchronization of linked issues.

These are the steps to follow:

• Create an Elements Copy & Sync recipe in your project.

• In the Fields section of the recipe:

  • Choose to modify the Labels field.

  • Use smart values like: linkedIssue.key to insert the key of the linked issue as a label.

• Trigger the recipe manually (via a button) or automatically (e.g., post function on issue creation).

The app is for free during 30 days (and it stays free under 10 users), so don't hesitate to give it a try!

[Bill Sheboy]

Hi @danish_khatri 

For the JSON expression you show, there are a couple of things preventing the update...

• That link smart value is to the outwardIssue object, not just the key
• That smart value is also a list of values, and thus even when there is only one linked issue, a list is provided...which likely will fail to create the lable

Assuming the created work item has one-and-only-one outward link, please try this expression in the JSON:

{{issue.issuelinks.outwardIssue.key.first}}

And as a safety check to prevent problems with other work item creations triggering this rule, you may want to add a smart value condition to confirm that key is in your software project.  This could be done with a text comparison, or if you increase the rule scope, with a JQL or other condition on the actual work item.

Kind regards,
Bill

[danish_khatri]

Thanks @Bill Sheboy

I'll try this out.

I even tried implementing the following but still it didn't update anything.

{{issue.issuelinks.outwardIssue.key}}

[danish_khatri]

Hi @Bill Sheboy 

Tried your recommendation but it is still not updating the ticket key no of the Linked Jira software project in the labels of Jira service desk ticket.

I believe since both the tickets are in different project i will have to update the scope of this rule, for the rule to fetch ticket no from other project and then update in label.

Thanks,

Danish

[Bill Sheboy]

First, changing the scope is not needed for this scenario: you are getting the key(s) as plain text from the {{issue.issuelinks}} smart value and not trying to interact with them as actual work items.

Next, from what you describe, I do not believe the links contain what you are expecting.  I recommend identifying an example work item and using this how-to article to view the complete JSON for that item: 

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Essentially, you use a browser tab to call the REST API to get the work item, and then search on the page for issuelinks and the data.  Then look to see if the content / structure matches what you expect.

[danish_khatri]

Hi @Bill Sheboy 

As recommended, i used REST API to get the work item and then found the smart value to be "inward" for the link issue. I updated my JSON to the following but it still didn't updated the labels with key of linked Issue (This issue is from other project)

{{issue.issuelinks.inwardIssue.key.first}}

Then i thought it might be wrong JSON update command i would be using hence i updated it to the following and still it didn't updated the label with key of linked Issue (This issue is from other project)

{
"update": {
"labels": [
{
"add": "{{issue.issuelinks.inwardIssue.key.first}}"
}
          ]
          }
}  

[Bill Sheboy]

When you checked, were there any other links present?

Please post an image of your current, complete rule in a single image, an image of the edit work item action, and of the audit log details.  Those may help explain what you are seeing.

And...if your rule is using the Work Item Created trigger, this could be a timing issue: that trigger has a problem where the rule can start before all data is available.  Seeing your rule image will confirm if this is the case.

If so, the next step would be to add the Re-fetch Work Item Data action immediately after the trigger (before other steps) and then re-test.