copying a user via automation from another issue

[BEN FRIEDMAN]

Hi,

the setup i have is this:

ticket A contains a custom field with value "x".

"x" is the summary of ticket B. 

ticket B has a sales rep field (user) with a "user's name".

ticket A also has a field for sales rep.

i need an automation that will run manually from ticket A, which will copy the sales rep from ticket B to ticket A. 

what i currently have is:

on manual triger

if ticket matches conditions

for JQL (summary ~ "x" and  issue type = ticket B)

  create a variable salesRep = {{issue.Sales/Account Manager.accountId}}

edit issue with JSON

{
"fields": {
"Sales/Account Manager": { "id": "{{salesRep}}" }
}
}

im getting the error that the account doesnt exist. 

any ideas how to resolve?

[Bill Sheboy · Accepted solution]

Hi @BEN FRIEDMAN 

I am guessing at your rule structure a bit, so please let me know if this helps...

Create Variable can only be set and not edited yet...but, values can be preserved if you handle scoping.  Here are two scenarios:

• Trigger: ...
• Branch: ...
  • Action: create variable varMyVariable setting it to {{issue.key}}
• Action: log the created variable varMyVariable

In this scenario, the variable is created within the branch and so when it goes out of scope, the logged value is empty.

• Trigger: ...
• Action: create variable varMyVariable initialize it to "null"
• Branch: ...
  • Action: create variable varMyVariable setting it to {{issue.key}}
• Action: log the created variable varMyVariable

In this scenario, the variable is created before and again within the branch using the same name, and so the value is preserved and logged.  Please note: this works only when the branch returns one-and-only-one issue; otherwise the asychronous processing of branches creates a new variable for each issue, and so is not saved.  One-issue branches are converted to in-line code.  To ensure your branch JQL evaluates to one issue, consider if you can replace the summary match with ~ to an exact key match.

Best regards,

Bill

[BEN FRIEDMAN]

that answer rocks!! i remember thinking about the scope as a possible issue as i was hammering my head against it, but would have never thought of the solution!!

can i ask how did you learn of this? and also about the note that you mentioned?

[Bill Sheboy]

I first learned about create variable with browser searches trying to solve some state management challenges in rules.  (You can also solve these with custom fields and entity properties...but those require use of the Re-fetch Action.  But, I disgress...)

Then I found this article on solving the scoping issue from one of the Atlassian folks.  I recommend reading the comments as several customers uncovered other "behaviors" of create variable.  It is a useful work-around for the one-issue case.

Regarding my note, the documentation on related issue handling describes the asychronous processing.  So for your use case the trick is how to make the branch find one issue and not be tricked by the "~" search if you only have the Summary?

You may try this in two steps: Lookup and then Branch on new JQL.

• ...your rule up to the point of branching
• Action: lookup issues on your JQL (summary ~ "x" and  issue type = ticket B)
• Advanced Compare Condition:  {{lookupIssues.size|0}} equals 1  (This should protect against unexpected conditions of zero or multiple matches.)
• Branch: on new JQL with key = {{lookupIssues.first.key}}
  • ...your rule after the branching