Linking issues across projects with the same field value with Automation

[Richard Canlas]

Why doesn't this work below?

[Bill Sheboy]

Hi @Richard Canlas 

I wonder if your branch JQL is too vague, and so there is confusion later about the fields.  Based on that error, there are definitely multiple custom fields getting picked up for different projects.

Perhaps change your branch to use this JQL to narrow things down before linking:

project = PMP AND issueType = story AND text ~ "supply chain" AND "Order ID" = {{triggerIssue.Order ID}}

Please confirm the name of the smart value for your Order ID field first.  You may do that using this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

And, the JQL may then require that you use the custom field ID to get it to work as a smart value.

Kind regards,
Bill

[Richard Canlas]

@Bill Sheboy 

Something is definitely off with my smart value for my Order ID. I've been at this all night and for the life of me can't figure out the correct JQL expression/smart value for my ID. 

I tried to read your article but it was very challenging to interpret. 

[Richard Canlas]

@Bill Sheboy So in that how to article,

I'm supposed to use this link

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

and input the html link of the page I'm on in <yourinstanceurl> and put my issue key at the <issuekey> section? It didn't work..

[Richard Canlas]

@Bill Sheboy 

I tried experimenting other ways some more:

*Note* The trigger that I'm doing in the screenshot is editing the Order ID field on the POR board. So the second rule that is set up is that it checks if that Order ID is x21r0a9 and then branches out to look for x21r0a9 on the PMP board.

So this time, even when I put the exact value for Order ID that I know exists in both POR and PMP, it still doesn't work for some reason. Perhaps something is off with my rules? In my "For JQL" script, there are 24 issues found. But only one of those issues have the "x21r0a9" Order ID, so I'm confused by the audit log saying that there's multiple fields with the same name and type. 

[Bill Sheboy]

Hi, Richard.  Sorry as I am catching up on the symptoms you note...please let me know if I miss anything.

Short answer: you will need to re-name one of the fields (probably the company-managed project one) to make this work.

Longer answer:

(1) You note that the URL from that article to find the smart values did not work.  What happened?  And, did you enter the URL like this, for example:

https:// my Instance Url /rest/api/2/issue/POR-2414?expand=names

(2) That rule you show clearly shows the second condition on the exact match to the custom field Order ID failing.  There is an open defect related to custom fields being declared in both a team-managed project and at the global scope for company-managed projects: https://jira.atlassian.com/browse/JRACLOUD-75705

The suggested work-around is to re-name one of the fields.  (There is a more complex work-around described in the defect comments to avoid the field re-name by altering the rule's JSON manually with export/import rules, and I recommend not trying that one.)

(3) You observed the JQL query is not returning the expected issues when checking on the Order ID field.  If this is inside of the rule, this is the same defect I noted in #2 above.  If it is in stand-alone JQL, it is this related defect: https://jira.atlassian.com/browse/JRACLOUD-74239

[Richard Canlas]

@Bill Sheboy Thanks, I may answer your questions in multiple posts. It's a lot to absorb. 

"And, did you enter the URL like this, for example:

https:// my Instance Url /rest/api/2/issue/POR-2414?expand=names"

What does "my instance url" mean? It's the page I'm currently on, right? So if I go to a ticket, I paste the whole URL into that section? If so, yes, that's what I did. 

(2) That rule you show clearly shows the second condition on the exact match to the custom field Order ID failing.  There is an open defect related to custom fields being declared in both a team-managed project and at the global scope for company-managed projects: https://jira.atlassian.com/browse/JRACLOUD-75705

The suggested work-around is to re-name one of the fields.  (There is a more complex work-around described in the defect comments to avoid the field re-name by altering the rule's JSON manually with export/import rules, and I recommend not trying that one.)

So if I understand correctly, I have to use a different Field title for one of the two boards. Okay, so I'll try using "Order ID(s)" for the one in PMP and the one in PMP will remain as "Order ID"

Let me try it out...

[Richard Canlas]

@Bill Sheboy It seems like it is stuck at POR-2419 because it is not reading the "x21r0a9" I inputted into Order ID field in POR. The Order ID equals x21r0a9 function isn't working. I wonder why?

I added the "Order ID(s)" into the rule set but I don't believe it's even making it that far because it's stuck on the POR board and not passing the first condition. See screenshot below:

Did I follow your instructions correctly?

[Bill Sheboy]

Yes, it does appear you made the changes correctly...and...the error in the audit log indicates there are still multiple fields with the same name/type in your Jira site.

At this point, I recommend working with your site admin to submit a ticket to the Atlassian support team.  They may see something in the logs (which customers cannot access) and so indicate what is happening.  You can do that here: https://support.atlassian.com/contact/#/

Once you hear back from them, please post what you learn so the community can benefit.  Thanks!

[Richard Canlas]

@Bill Sheboy thanks for the tip. I did reach out to support and they are working on my issue. I did confirm that the team-managed and company-managed projects are affecting what I want to do by testing it across company-managed projects and it worked. But now, I have a new issue that I was wondering if you could help me with. 

The following automation works:

The "Then: Edit issue fields" at the end of the rule is a test to see if it works. Instead, what I want to do is update the Epic Link of the Trigger Issue by copying from the Epic Link of the verified matching ticket in PMP after the branching rule has verified that the Order ID(s) is the same as the Order ID of the Trigger Issue.

The branching component leads to a story (as shown by the JQL) and I want to grab the Epic Link that's already linked to that story and copy it to the Epic Link of the Trigger Issue. 

Do you think this is a "lookup" issue after the "Order ID(s) contains" component? To look up the trigger issue again after verification of matching Order ID so that the change can apply to the trigger issue instead of the branching? 

Thanks for all your help!

[Bill Sheboy]

Hi, and regarding your question:

Do you think this is a "lookup" issue after the "Order ID(s) contains" component? To look up the trigger issue again after verification of matching Order ID so that the change can apply to the trigger issue instead of the branching? 

Yes, you probably need to use lookup issues to get the value in order to perform the edit of the trigger issue.

In an automation rule, the edit issue action impacts the one in the current scope level of the rule.  So if you are inside of a branch, the issues from the branch are edited (not the trigger issue).  For example...

• trigger...
• action: edit issue <<< this changes the trigger issue
• branch: on JQL (or any branch other than "current issue")
  • action: edit issue <<< this changes the branched-to issue
  • ...
• ...more actions
• action: edit issue <<< this changes the trigger issue
• ...

If you can use a lookup issues action to get the epic link (key) you can then use it to update the trigger issue.

[Richard Canlas]

@Bill Sheboy 

Good news. I figured out how the initial question of this thread:

Now the issue remains looking up the Epic Link that's tied to the JQL in the photo and copying it to the trigger issue. After reading your explanation, I'm still stuck on it. Wondering since I've diverged from the original question if I should make an entirely new community question. 

Here's the problem i'm dealing with:

• trigger...
• action: edit issue <<< this changes the trigger issue
• branch: on JQL (or any branch other than "current issue")
  • action: edit issue <<< this changes the branched-to issue
  • ...
• ...more actions
• action: edit issue <<< this changes the trigger issue
• ...

So here, I understand that I'm branching off to the JQL (other than trigger issue), but I need to only get the Epic Link from that branch and then exit out of the branch to get the copied Epic Link from the branch and into the trigger issue. 

[Richard Canlas]

@Bill Sheboy 
I've never used the "create variable" component. Maybe that's what I should use here? Problem now is what the smart value is while I'm in the branch. How do I pull the Epic Link using a smart value while I'm inside that JQL which is searching for the Story tied to an Order ID? {{issue.epic.key}} ? 

So once I create the variable using that, then I can transfer the variable name into the trigger issue outside the branch??

[Bill Sheboy]

Another automation, by-design thing will prevent using create variable that way: branches returning more than one issue run asynchronously, and so you cannot find/save in a created variable within the branch.  (There are few posts on this if you want to read more.)

Let's try to get specific you your use case. Try updating your rule this way to see what helps.  I have merged your branch and condition JQL, and highlighted the changes in italics:

• trigger: value changes for Order ID
• condition: project is one of Procurement (POR)
• action: lookup issues on JQL
  • project = PMP AND issueType = story AND text ~ "supply chain" AND "Order ID" = {{fieldChange.toString}}
• advanced compare condition: testing if the lookup returned 1 and only one issue
  • first value: {{lookupIssues.size|0}}
  • condition: is equal to
  • second value: 1
• action: edit trigger issue with the epic link from the lookup issues
  • {{lookupIssues.first.epic link}}

Please note the advanced compare condition: it is testing if you only get one issue back, so if you expect more your rule may not work to solve this problem.

[Richard Canlas]

For some reason it's not finding my lookup issue. (Sorry I had to switch use case a little bit, but I don't think it impacts the scenario)

[Bill Sheboy]

Hmmm....

Before your call to lookup issues, please try writing {{fieldChange.toString}} to the audit log to see what it shows.

Next I note you are using the custom field id in that lookup's JQL.  Why not just use the field name as the JQL should be able to use it?  If not, have you confirmed that is the correct custom field ID?

Thanks!

[Richard Canlas]

@Bill Sheboy 

How do you write that to the audit log? When I go to the audit log, it just opens up a list of all the rules performed to date. I do not see a field to enter it. 

The reason I am using the look up is for the trigger issue to locate the Epic according to the Order ID stated in the Order Issue when it's created/edited. There are multiple "Planning" Epics and they are unique by the Order ID in each issue. Yes, it is the correct custom ID since it works for my other rules using that custom ID. 

[Bill Sheboy]

There is a rule Log action which can write a value for review later in the log.

Thanks for clarifying on the custom field.  Based on what you showed for the log, that indicates something is not matching the JQL for the lookup as expected.

After you write {{fieldChange.toString}} to the audit log and confirm the value, please try to run the JQL from your lookup manually in Advanced Search using that value.  That should help identify why the issues are not matching, and so indicate what to modify to make it work.

[Richard Canlas]

Hey @Bill Sheboy 

The log action works for the change.tostring

Now I should put that same smart value inside lookup? Let me do that

[Richard Canlas]

This is what happens inside lookup

[Bill Sheboy]

As you are checking for a string, you will need to put quotation marks around the smart value in the lookup JQL.  Sorry that I omitted those earlier:

project = PMP AND issueType = story AND text ~ "Planning" AND cf[11100] = "{{fieldChange.toString}}"

Of note: if your custom field is not a text-type field, the contains operator "~" does not work in JQL.

[Richard Canlas]

Hey @Bill Sheboy Bill,

The rule seems to be a "Success" but when I look inside the issue (PMP-439, the trigger issue), the Epic Link is unchanged. 

[Bill Sheboy]

What is the smart value you are setting to the Epic Link field in the edit?  You probably want something like {{lookupIssues.first.Epic link}} based on what you described.

And, if you write your smart value to the audit log, what do you see?

[John Funk]

Hi Richard,

The error says you have multiple custom fields with the same name. Is that the case? Is this team-managed project? 

[Richard Canlas]

Hi @John Funk 

The Procurement (POR) is a team managed project

The other one, PMP, is a company managed project

[Richard Canlas]

I do have multiple tickets with custom field "Order ID" of the same name, but I thought I tried to narrow that down with my "For JQL" to find a specific Story within the PMP board @John Funk 

[John Funk]

Have you created the same field in multiple team-managed projects? 

[John Funk]

I don't think it is ever getting to your JQL - it is failing at your second condition. 

[Richard Canlas]

@John Funk Yes, the same field "Order ID" is in both the POR and PMP boards. However, one is team managed, and the other is a company managed. 

So it is failing at the "Order ID contains same as the destination issue"

The reason I configured it that way is I want the Order ID in POR to be grabbed from the Order ID in PMP. Is the fact that I put "destination issue" wrong? I thought it grabs it from the branch below. 

[John Funk]

I don't know that you need that condition at all. 

[Richard Canlas]

@John Funk 

Okay, so I removed that condition and it gives me this:

So I guess the issue now is that the JQL is not specific enough to target the one ticket I want... any suggestions?

This is what some of my tickets look like:

Initiative#1

>>Epic#1

>>>Story titled "Supply Chain , unique ID #1"

Initative#2

>>Epic#2

>>>Story titled "Supply Chain, unique ID #2"

[John Funk]

The way we typically solve this is to first link the two issues using the lookupIssues function. See screenshot (but note that the transition has nothing to do with the linking)

Then we create a second rule that is triggered by the linkage and does the update to the second project. 

[Richard Canlas]

@John Funk 

How did you do your "Link Issues to" to a JSON script? My drop down doesn't  have that:

[Richard Canlas]

Ok, I'm trying to wrap my head around the lookup function and what you mean

My interpretation:

I should have two rules. 

Rule#1 Trigger is creation of issue in POR board. Then lookup the issue in the PMP board. Then Link issue by the smart value you used in your screen shot.

Rule#2 Trigger upon linkage of the two issues that were linked via Rule #1. The common Order ID field in PMP will be copied to POR Order ID. 

I have a question regarding this method. In Rule #1, I'm using what's inputted in the Order ID of POR board to lookup the issue in the PMP board. If that is not a factor, then it looks like I'm looking directly for a ticket that must be specified by the automation and not by the Order ID. 

@John Funk 

[John Funk]

Yes, there must be something in common between the two cards to link them. What is it that is in common?

[Richard Canlas]

@John Funk the common thing is the Order ID custom field

I want the Order ID in POR (when it gets inputted upon creation) to find the Order ID in PMP and link it. Problem is, there could be multiple stories and epics with the same order ID in PMP, but the specific one I want to tie it to is the Story with a Summary Title with text "Supply Chain".