Jira Automation: JSON & how to use parent issue custom field as assignee for sub task

[Bård Karstensen]

Hi! 

I am trying to use JIRA Automation to create sub tasks in a parent issue, as a part of onboarding. This means the parent issue will be created by somebody, and a custom field - Manager - where the JIRA user responsible for the new employee will be selected. 

So, I can create the sub task when the parent issue is transitioned, but I am struggling to set the Manager as an assignee for the sub task. 

I am trying to add this as a JSON script under More options / Additional fieldsat the bottom of the Sub Task feature, but the rule fails to add assignee. I have tried with various variations of triggerissue, parentissue, .key, .accountId and so on. 

{
"fields": {
"assignee": { "id": "{{triggerissue.customfield.10091.accountId}}" }
}
}

Any help is greatly appreciated. Thanks! 

[Bill Sheboy · Accepted solution]

Hi @Bård Karstensen 

I notice there is a typo in your JSON expression:

{{triggerissue.customfield.10091.accountId}} should be 
{{triggerissue.customfield_10091.accountId}}

Kind regards,
Bill

[Bård Karstensen]

Thank you @Bill Sheboy 

This solved the problem for me. 

[Emma Hecht]

@[deleted] 

Hi! I'm looking to do something similar but can't get this solution to work for me. I have issue type "Article" with a custom people field for "Manager" (custom field ID 11134). When creating an issue of this type, I will fill the Manager field in with either "Aaron" or "Bobby".

I want to automatically assign the "Approve" task to Manager each time it is created, depending on who the Manager is, either Aaron or Bobby.

Here are a few things I have tried:

With these, the Approve subtask is created, but the Manager (Aaron or Bobby) is not added as the assignee (blank assignee field) —

With this, the Approve subtask is not created and it runs with an error —

If you could advise, I would appreciate it so much! Thanks! 

[Bill Sheboy]

Hi @Emma Hecht 

First thing, you seem to be trying to set the assignee in two places, with the field and in the advanced edit with JSON.  Try clearing out the advanced edit.

Next, would you please post images of your complete rule and the audit log showing details of a rule run?  Those may provide context for what is happening.  Thanks!

And just to confirm, is this for a team-managed (TMP) or a company-managed project (CMP)?  I am guessing TMP as you note have a People field type.

Kind regards,
Bill

[Emma Hecht]

@Bill Sheboy Hi! Thanks so much for your response!

On the Assignee field and Additional fields — I ran each of those tests separately (so if I had something in the Assignee field, I didn't have any JSON in the Additional fields and vice versa)

Images of the rule —

Audit log (the whole log is configuration change > some errors, with some errors always being this same JSON message) —

Last, yes this is a team managed project, which allows me to create the custom person fields like below for issues —

[Bill Sheboy]

This is curious...I tried your scenario and it worked for me...

• I added a single-select People field to a team-managed project
• triggered the rule from an issue
• added an action to create a subtask for the trigger issue
• and tried to set the assignee from the field, using both the field name and custom field id, with the accountId
• both worked for me

Rules sometimes get "glitched" when adding/removing the advanced edit with JSON stuff.  Let's try this: disable this rule, and recreate it from scratch and retest.

[Emma Hecht]

That worked! Thank you SO much!

[Emma Hecht]

@Bill Sheboy 

Follow-up question — should the custom field smart key work for sending emails? I'm trying to use it in the "to" field for an email notification, but I'm getting an error:

To field:

Issue path:

Audit log:

[Bill Sheboy]

Sadly, not yet...For some reason the People-type field's design in team-managed projects does not support the user attributes like email address.

Here is the suggestion to add that information, which you may watch/vote for to see progress: https://jira.atlassian.com/browse/JSWCLOUD-22200

The work-around depend on usage...

• for a fixed value, hardcode in the email address
• if you are setting the assignee based on a People-type field, try a Re-fetch action after the assignment and then try to use the assignee's email address instead
• brute force approach: using the display name from the People-type field, call the REST API to get the user's information and use that to send the email.  This will add a few seconds to each rule execution.

[Emma Hecht]

@Bill Sheboy 

Interested in learning how to implement the REST API solution! (So sorry, I don't have a strong background in coding or Jira). Can't find much on how to do this in Jira Is there an article I'm missing or would you be able to post a screenshot or the code?

Context: When I'm moving a certain subtask from "upcoming" to "done" I want to send an email to another user (not the assignee or one of the Jira-defined person fields, like reporter).

Thank you!

[Emma Hecht]

@Bill Sheboy 

Actually, figured out a simple workaround! Thanks so much for your help here! :) 

[Bill Sheboy]

Well done!

For future reference if you need to call the REST API for things automation rules do not support directly, please see this how-to article:

https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

With your use case of getting the email address from the account Id, the method to call would be this:

yourJiraUrl/rest/api/2/user?accountId=theDesiredUserAccountId

[Trudy Claspill]

Refer to the image below.

In field #1 choose Assignee.

In field #2 choose Copy From Parent.

[Bård Karstensen]

Thank you @Trudy Claspill 
This could have been a solution, but in this particular case the assignee for the sub tasks would not always be the same as assignee for the parent issue.