Issues setting a custom field from linked issue

[Parag Ahire]

Hello, I have the below requirement.

Project A has a custom field named CausedByIssueKey. I want to populate this using an automation rule with the value of key from Project B. An issue from Project B is linked to an issue in Project A using the "caused by" relationship.

I tried following multiple pre-existing articles on this topic but am not able to make it to work.

Please help with specific steps to take to make this automation rule work.

Thanks in advance.

[Trudy Claspill · Accepted solution]

Hello @Parag Ahire 

What event should cause the rule to execute?

1. Is this going to be a scheduled rule?
2. Do you want the rule triggered when the value of in an issue in Project B changes?
3. Do you want the rule to run when an issue from Project B is linked to an issue in Project A?

Can the issue in Project A be linked to more than one issue in Project B with the same link relationship?

[Trudy Claspill]

Do you have any administrative access in Jira? Are you a Project Administrator for either or both Project A and Project B? Are you a full Jira Administrator?

Because this rule involves multiple projects it will need to have a scope that includes both projects. Only a Jira Administrator can create a rule that has multiple projects in its scope. If you are not a Jira Administrator you will have to get a Jira Administrator to create the rule for you.

Making sure that I understand the relationship you are creating, which of these is correct?

1. B-111 is caused by A-222
2. A-222 is caused by B-111

[Parag Ahire]

1) I am an administrator just for my project which is Project A.
2) Not an administrator for Project B.

3) Not a full Jira Administrator.

Relationships would be as below.

B-11 exists first and then A-222 is created.

A-222 is caused by B-111.

B-111 causes A-222.

Thanks.

[Trudy Claspill]

I can share the automation rule here, but if you are not a full Jira Administrator you will not be able to implement it in your instance. You will have to work with a Jira Administrator to get that done.

Here is the rule:

In my instance "Problem/Incident" is the name of the link type that provides the "causes"/"is caused by" relationship.

When you use the Link Issues trigger, that is a special case where the rule is actually triggered by the issue that shows the Outward Description part of the link relationship. So, regardless of whether you create the link from the Project A issue or the Project B issue, the rule is triggered by the issue that shows it "causes" the other issue. In the below screen image issue CS-85 displays that it "causes" CMSB-11, so it is CS-85 that is the issue triggering this rule.

With the Link Issue trigger the rule has a special option to recognize one of the issues as the "source" issue, and one as the "destination" issue. The one that is the "source" is the one that triggered the rule. The issue to which it has been linked is the "destination" and can be referenced with the special smart value {{destinationIssue}}

The conditions after the trigger ensure that the rule will continue to process only when it is triggered by a link being created from an issue in Project B to an issue in Project A. This is necessary because the Rule Scope must name both projects. Without these conditions the rule could execute when an issue in Project A was linked as "causes" an issue in Project B.

You want to update the issue in Project A, but with this rule it is the issue that is in Project B that triggered the rule. So you need to use a For Branch component to change the focus to the issue in Project A. Because the Link Issue trigger is used, we can use a special option in the For Branch to specify changing the focus to the "destination" issue in the linked pair.

And then, lastly, you use an Edit action to edit your custom field in Project A to add the value from the source issue (Project B). Because the source issue is the one that triggered the rule you can use the smart value {{triggerIssue}} to reference that issue. I used the Summary field in my example.

[Parag Ahire]

Thanks @Trudy Claspill . I will try this out and get back in case of obstacles.

[Parag Ahire · Accepted solution]

Hello @Trudy Claspill 

1. It will be an automation rule.

2. It will be triggered when an issue in Project A is associated with an issue in Project B with the "caused by" relationship.

3. Correct, when an issue from Project B is linked to an issue in Project A. This is because issue in Project A will be created only if the issue in Project B pre-exists.

4. It is possible that issue in Project A can be linked to more than one issue in Project B but for simplicity we can assume there is only one such link.

5. If it simplifies things then both the issues in Project A and Project B will be epics in my use case.

Thanks.

[Parag Ahire]

Hello @Trudy Claspill - these are the steps I followed. I did not get the expected result.

Rule layout (project names erased - first Project-B and second Project-A)

When block

Project Equals (1st - Project-B)

Project Equals (2nd - Project-A)

For block

Then block (field is Dependency and is chosen) 

Tests :

1) While in Issue-1 of Project-B, create a causes link to Issue-2 in Project-A

Expectation : Dependency Field in Issue-2 of Project-A is set to Issue-1

Result : Dependency Field in Issue-2 of Project-A is blank

2) While in Issue-2 of Project A, create a caused by link to Issue-1 in Project-B

Expectation : Dependency Field in Issue-2 of Project-A is set to Issue-1

Result : Dependency Field in Issue-2 of Project-A is blank

[Parag Ahire]

@Trudy Claspill - You might ask for the audit log. So, here is the image. Rule did not trigger.

[Trudy Claspill]

Sometimes there is a delay in the updating of the Audit Log screen. Please check it again to see if logs have shown up.

Please show us the information from the Issue Linking configuration screen that shows the Inward and Outward Descriptions for the "Cause" link type.

https://yourBaseURL/secure/admin/ViewLinkTypes!default.jspa

Additionally the two conditions that you have immediately after the trigger are going to block the rule from executing. In this scenario you can't use the Issue Fields Condition. You need to use the {{smart value}} Condition 

[Parag Ahire]

Hello @Trudy Claspill  Here are some screen images as requested. The rule hasn't triggered as per the audit log.

Note:

i) Project names, user names have been intentionally erased.

ii) The JIRA admin created the rule by entering Project Settings / Automation of Project A.

iii) Third screen below shows that the scope is limited to Project A even though the rule was created by JIRA Administrator. Is that a cause of an issue ?

[Trudy Claspill]

The third screen indicates the rule was not set up as a multiple-project scoped rule. And yes, that is the reason the rule is not being triggered.

To create a multiple-project scoped rule the Jira Administrator must navigate to the Global Automation screen.

https://yourBaseUrl/secure/AutomationGlobalAdminAction!default.jspa#/

When creating the rule there the administrator will need to change the Scope field to "Multiple projects".

The administrator will then need to specify your A and B projects in the "Restrict to projects" field.

[Parag Ahire]

Thanks @Trudy Claspill 

We were unable to find the Global Automation screen. This below URL did not work for our JIRA Administrator.

https://yourBaseUrl/secure/AutomationGlobalAdminAction!default.jspa#/

We get a 404 error.

"Oops, you've found a dead link."

[Trudy Claspill]

I apologize. I was looking at an on-premise instance.

The URL for Cloud is

https://yourBaseUrl/jira/settings/automation

[Parag Ahire]

Thanks @Trudy Claspill . I think we are close to get this to work.  This is the audit log.

What are we missing ?

[Trudy Claspill]

Hello @Parag Ahire 

In order to help debug the rule I am going to need you to identify the projects referenced in the steps and the projects for the issue that are referenced in the execution log for the rule. You can paste "A" and "B" into the images.

What the log is indicating is that the issue considered the "source" in the link relationship if failing to match the first condition.

This condition should be checking that the issue considered the source if from the project where the issue has the "causes" side of the link. If the issues in Project A are linked to indicate they cause the issues in Project B:

A-111 causes B-222

...then the first condition needs to check that the project key equals "A", and the second condition needs to check that the project key equals "B".

The two issue referenced in the audit log are X-1821 and Y-12772.

The log is telling me that it considers X-1821 to be the "source" issue, which means that the link was created thus:

X-1821 causes Y-12772

Y-12772 is caused by X-1821

Since X-1821 is considered the source, and the first condition is failing to be met, that tells me that the first condition is not checking that the source issue is in project X.

Either the link was created backwards or the conditions name the wrong projects.

[Parag Ahire]

Hello @Trudy Claspill  here are the screen images

Steps taken to test

a) Create Issue B-1 under Project B

b) Create Issue A-1 under Project A

c) While in Issue A-1 from Project A, add a link with "caused by" relationship and associate Issue B-1 from Project B (actual result Field 1 under Project A is blank; expected result is that Field 1 under Project A is set with value B-1)

d) c) While in Issue B-1 from Project B, add a link with "causes" relationship and associate Issue A-1 from Project A (actual result Field 1 under Project A is blank; expected result is that Field 1 under Project A is set with value B-1)

What are we missing ?

Note: Rule is created by a JIRA administrator as a Global automation rule.

[Trudy Claspill]

Can you provide the Audit Log execution details for (c) and (d), indicating which log is for (c) and which is for (d), and labeling the issues in the logs as from project A or project B?

[Parag Ahire]

@Trudy Claspill 

Audit log for (c) above.

Audit log for (d) above.

[Parag Ahire]

@Trudy Claspill - Could you also provide me {{smart values}} condition for checking an issue type in source and destination project is an Epic. I would like to add that clause too as an additional if condition.

[Trudy Claspill]

Can you confirm that in the two conditions:

...you have used the correct project keys for each project? Note here you need to use the project keys, not the project names. The keys are the alphanumerics that appear to the left of the dash in the issue keys; i.e.

BBB-123 - key is BBB

AAA-456 - key is AAA

And also make sure that you have used the correct case. Project Keys are usually all capitalized.

You could insert Log Actions before these Conditions to print the keys into the rule execution log to confirm that your smart values are getting what you expect:

[Parag Ahire]

@Trudy Claspill I need the rule to be generic and not just work for two specific project keys one from each project A and B. How should I change the rule to achieve that ?

Essentially, I want to check that the issue was created against Project A and Project B and both were an epic.

[Trudy Claspill]

I am no longer sure what you mean when you say "Project A" and "Project B".

A "Project" in Jira is a specific entity. A Project has a Name, and a Key, and it is a container for issues of various Issue Types. A Project has configurations for Notifications, Permissions, Issue Types, and Workflows.

Projects are listed on the View all projects page accessed from the Projects menu.

When you say Project A and Project B, are you referring to these types of Projects? Or are you using the term "project" to refer to something else?

Assuming we are talking about the same thing when we say "project", meaning the entities that list on the View all projects page, and you want this rule to work for multiple projects, then my next questions are...

1. Do you want it to work for all projects where a "causes" link is created between two Epics? Or only for a subset of projects?
2. Should it only work if the two linked Epics are in different projects? Or should it also work if the linked Epics are in the same project?
3. Given that you want it to work for multiple projects, not just one specific pair of projects, does it actually matter which specific project has the source issue and which has the destination issue?

[Parag Ahire]

@Trudy Claspill - Correct, I am referring to "Project" as something one sees listed under View all projects. So, A and B are seen there and thus are projects.

Referring to your questions above

1. I want the automation rules to only work for a "caused by" or "causes" relationship across epics in Project A and Project B.

2. Rules should only work when the two epics are in Project A and Project B respectively. Rule should work in either of the two circumstances (at least one scenario working is also fine to begin with)

a) When an epic in Project A is linked by a "caused by" relationship with an epic in Project B.

b) When an epic in Project B is linked by a "causes" relationship with an epic in Project A.

3. Rules should only work when the two epics are in Project A and Project B respectively. Project B is the source and Project A is the destination as per the automation rule we created above.

[Trudy Claspill]

Wonderful - we are using Project to mean the same thing.

You said you don't want this limited to two specific projects. Do I understand that there will be multiple projects that you are referring to collectively as "Project B", and multiple projects that you are referring to collectively as "Project A"?

You said you want the rule to run only when the Types of both issues are Epics. In that case you need to add Conditions, similar to the project key Conditions, to check the Types of the source and destination issues.

Do I understand correctly that you want this rule to run only when the source issue is in one of the "B" projects and the destination issue is in one of the "A" projects?

If that is correct, does this need to be for specific pairs of B and A, or can the source be in any B project and the destination in any A project?

If you want

1. this rule to run for multiple "pairs" of projects where
2. issues from any of the B projects gets linked as "causes" an issue in any of the A projects
3. and not run in any other case ("cause" links created between other projects, or an A project issue "causes" a B project issue)

then your Conditions are going to have to check for the project keys of the "B" and "A" projects respectively. And all the "B" projects and all the "A" projects will need to be listed in the Scope.

If you don't care which at all in which project the source issue exists or in which project the destination issue exists, and you want this rule to run any time a "cause" link is created between two Epics in any pair of projects or within one project, then the rule Scope can be changed to Global (All Projects), and the Conditions to check the project keys can be removed.

----

With regard to the smart value to use for checking the issue Type, you can find information about available smart values here:

https://support.atlassian.com/cloud-automation/docs/smart-values-in-jira-automation/

If you drill into the documentation for the smart values for Issues you can find the information for the appropriate smart value to use when you want to look at the Issue Type.

[Parag Ahire]

@Trudy Claspill 

1) There is only a single Project A and a single Project B

2) I want to run the rule only when epic in source project B is linked to an epic in destination project A by a causes / caused by relationship.

3) I want the rule to run when any epic in source project B is linked to any epic in destination project A. In other words, I do not want the rule to work for only this specific linking but any linking of epics across Project A and Project B at the time the linking is done.

B-1821 causes A-12772

A-12772 is caused by B-1821

I do not want to hard code the issue # of project A and project B in the rule.

[Trudy Claspill]

Hello @Parag Ahire 

You do not have to hard code the issue numbers from Project A and Project B. 

You must provide the Project Keys in the Conditions that I specified after the trigger. If you don't provide the project keys here you cannot limit the rule to executing only when the source issue is in Project B and the destination issue is in Project A.

You can add a check of the issue type for the trigger issue using a simple Issue Fields Condition.

You can add a check for the destination issue type using a Smart Values Condition.

That should satisfy all your requirements.

[Parag Ahire]

@Trudy Claspill - Success finally.

Thanks for the inputs and walkthrough.

[Trudy Claspill]

I'm glad we finally made it!

Please consider clicking on the Accept Answer button to mark you Question as Solved. That will help others searching the community find the posts with validated solutions.