Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

copying a user via automation from another issue

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?

1 answer

1 accepted

2 votes
Answer accepted

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

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?

Like John Funk likes this

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

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Marketplace Apps & Integrations

Bitbucket Smart Commits vs. Genius Commits - What's the difference?

If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...

130 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you