Jira automation fill out null when drop down is empty

[philip.song]

Hi, 

I'm using a Jira automation rule to fill out Ticket 1 based on the fields in Ticket 2. I'm using the Create Work Item component with the additional fields. 

I have a custom field customfield_15842 that is a drop down selector for the user. Sometimes it's empty and that's okay. However when it IS empty, and the automation is run, there is an error "Specify a valid value for YourCustomValue (customfield_15842 ),", which I gather is because it's trying to bring in a null value.

What I would like to do is write this logic such that if the value is empty, then just keep the field as `None`. But I'm having trouble writing the correct logic for this, and it keeps erroring.

I've tried things similar to the following with no luck:

"customfield_15842" : { "value": "{{triggerissue.customfield_15842 | null}}" }
"customfield_15842" : { "value": "{{#if(or(customfield_15842.isEmpty,equals(customfield_15842,null)))}}null{{/}}{{customfield_15842}}" }
"customfield_15842" : { "value": "{{#if(or(customfield_15842.isEmpty,equals(customfield_15842,null)))}}""{{/}}{{customfield_15842}}" }
"customfield_15842" : { "value": "{{#if(customfield_15842.isEmpty)}} null"}
"customfield_15842" : { "value": "{{#if(customfield_15842.isEmpty, null, triggerissue.customfield_15842)}}{{/}}"}

Any help appreciated, thanks!

--------

Update: Solved! 

It seems that when dealing with these drop down type fields, the if statement encloses the "setting" aspect. Something like this worked for me.

{{#if(exists(triggerIssue.customfield_15850))}} 
"customfield_15850": { "id": "{{triggerIssue.customfield_15850.id}}" } {{/}}

so when for example combining drop downs and regular text fields, it would look something like this, with the comma being contained inside the if statement

{{#if(exists(triggerIssue.customfield_15850))}} 
"customfield_15850": { "id": "{{triggerIssue.customfield_15850.id}}" }, {{/}}
"customfield_15851" : "{{triggerissue.customfield_15851}}"

A second aspect about copying drop down values is in particular cases where the fields may have different names but the same values, you cannot use the .id attribute. In cases like this, you can use the value attribute instead:

{{#if(not(exists(customfield_10550)))}}
 "customfield_10550": { "value": "{{triggerIssue.customfield_15845.value}}" }, 
{{/}}

[Bill Sheboy · Accepted solution]

Hi @philip.song 

I am starting a new answer to this question to avoid colliding with the other suggestions, and to provide more ideas to try...

First, what type of project are you using: company-managed or team-managed?

Next, if using team-managed what is the type of your custom field: a global, user-selection field or a team-managed People field?  That impacts how to use the JSON in the action because People fields are implemented as if they are always multiple-selection, and thus use the array syntax.

What I meant was using the variable for the entire JSON expression and to correctly test for the presence of the field with exists() in the condition:

• action: create variable
  • variable name: varJson
  • smart value:

{
  "fields": {
    {{#if(exists(triggerIssue.customfield_15842.accountId))}}
      "customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }, 
    {{/}}
    "customfield_15851" : "{{triggerIssue.customfield_15851}}"
  }
}

• action: Log, to write to the audit log
  • my JSON is: {{varJson}}
• action: create work item
  • using {{varJson}} in the advanced edit

Finally, please show an image of your entire Create Work Item action.  It is possible you are selecting overlapping options and that is causing the error.  For example, by selecting the field from the dropdown list AND trying to set it with JSON.

Kind regards,
Bill

[philip.song]

Hi @Bill Sheboy 

the flow of my automation is:

create variable (issues)
Branch rule (for each key in issues)
Create work item

The summary causes the rule to error which atm is intended to prevent issues from being created during testing

[Bill Sheboy]

For testing, you could create the variable with the JSON as I described earlier, and write that to the log and remove the Create Work Item action.

Please try that to confirm the JSON matches what you expect.  Once it works, you may re-add the Create Work Item action to test further.

[philip.song]

Hi @Bill Sheboy

Sorry I think I wasn't clear - I was able to put in the variable and output it in the log, but it's pulling through as empty, similar to Gor's suggestion but slightly different.

{ "fields": { "customfield_15851" : "" } }

I thought it was maybe because I'm confusing when to use issue vs triggerissue, so I may need to look into it more

[Bill Sheboy]

Please post images of your entire rule in one continuous image and of the audit log showing the rule execution.  Those may explain why the value is empty.  Thanks!

[philip.song]

Hi @Bill Sheboy 

I found an issue with the field I was pulling through so this works now, thank you!

Could you explain how/if the accountid suffix is needed? I think of pulling just the value of the field, so I'm not understanding it's impact

[Bill Sheboy]

Awesome; I am glad to learn it is working now!

For a custom fields with structure (e.g., select-option, user, version) they have different attributes.  For user-selection fields, those include the accountId, displayName, emailAddress, etc.

When a custom field is referenced in a rule as just this:

{{issue.customfield_12345}}

The automation uses whatever the developers determined was the default attribute to identify the value.  For user fields, that is accountId.  And so it would be the same as this:

{{issue.customfield_12345.accountId}}

However, context is important.  Multiple-selection fields produce a list of values.  And if that field is inside a list of work items, such as Lookup Work Items, we now have a list of lists of values, such as the following with some fake values:

[A, B, C], [D, E, F], [B], [], [H, J]...

Knowing your context (and using the rule's audit log) will help decide how to proceed and what smart value expressions to use.

[philip.song]

@Bill Sheboy understood, thanks again!

[philip.song]

Hi @Bill Sheboy 

This is back to not working in a very confusing manner :)

Here is the logic of the complete automation:

The text I'm putting into the variable is this:

{ "fields": {
{{#if(exists(triggerIssue.customfield_15850.accountId))}}
"customfield_15850": { "id": "{{triggerIssue.customfield_15850.accountId}}" },
{{/}}
"customfield_15851" : "{{triggerIssue.customfield_15851}}" } }

This field customfield_15850 I'm confirming is the field I think it is by using the python jira api (I don't think I otherwise have access to figure out what the field is in the jira browser)

^ Here I'm confirming that in issue CC-8, the customfield_15850 field corresponds to `Disease Frequency` which is indeed a dropdown

Finally, when I look into the log itself, it just shows an empty field:

Hope this is clear enough!

[Bill Sheboy]

Short answer: if you are trying to gather the custom field's data for a set of work items, use the Lookup Work Items action to gather them with the JQL, and then create the variable based on the results.

Branches which could be over more-than-one-thing are processed in parallel and asynchronously, with no guarantee of when the branch will complete up until the last step of the rule.

And so for the rule image you show:

• on each loop through the branch, the created variable is disposed of when it goes out of scope
• the write to the audit log is outside of the branch and thus...
  • it will always be empty, and
  • even if the value could somehow be "accumulated", the write to the log would likely happen before the branch finishes

[philip.song]

The workflow is

Ticket is created -> Automation is triggered, looks up the created ticket (which it has no problems doing) -> read fields from created ticket, create new ticket. 

In the event that I want to do this for multiple issues, I don't have any issues if they're created in parallel/out of order.

Are you saying that within the scope of the branch, all the triggervalues (which I intend to reflect CC-8) don't exist?

[Bill Sheboy]

Are you saying that within the scope of the branch, all the triggervalues (which I intend to reflect CC-8) don't exist?

No, I was not.  When a rule has a trigger issue, the {{triggerIssue}} smart value is available throughout the rule. 

I was describing because of the type of branch you used, the created variable is not available after the branch, or even shared between loops through the branch.

And considering what you just described for the flow, have you tried a rule with no branching:

• trigger: work item created
• action: re-fetch work item data
• action: create variable (to build the JSON)
• action: create work item, using the variable as needed

[philip.song]

@Bill Sheboy  I'm not sure that works for my case but you can tell me otherwise. 

The trigger issue is created via a form, which has an input field (call associated tickets which is a comma delimited list of other CC tickets). The action I want is for each associated ticket to create a subtask, and the information in that subtask is copied from the trigger issue. 

I tried to use a different way of branching (lookup work items, create variable, advanced branch. 

(The create variable is simply using {{lookupIssues}} as I suspect this is how it's intended to be used).

When I then create a workitem within the branch with this json:

{{#if(exists(issue.customfield_11278))}}
"customfield_11278": { "id": "{{issue.customfield_11278.id}}" },
{{/}}

"customfield_15851" : "{{issue.customfield_15851}}",

This actually works perfectly and as I intend. The problem is that the subtask is a child of the trigger issue (the Jira Form), and not the associated ticket even when the parent is set to the Current work item, and not the trigger item.

Also, regarding the previous post, I also tried to pull the creation into the loop, but that doesn't work either:

All the other fields pull through, except for the dropdowns

[philip.song]

Actually, I did get this to work in the original branch method using the above logic:

{{#if(exists(triggerIssue.customfield_15850))}} 
"customfield_15850": { "id": "{{triggerIssue.customfield_15850.id}}" }, {{/}}

However this syntax doesn't seem to work when using the "edit work item" component (which is not in scope of this ticket). I'll try to keep messing around with it 

[Bill Sheboy]

Thanks for the additional tests and clarification on the scenario.

Assuming the trigger is Work Item Created, the rule could use either:

1. The JQL Branch over the custom field, which allows adding subtasks to each branched-to issue
2. The Advanced Branch over the data instead, which would allow setting the parent field for each subtask as needed

For either approach please use:

• Build the JSON before the branch as a variable, and using that variable in work item create inside the branch
• When creating the work item, ensure each field is only set once.  That is...
  • The create and edit work item actions allow either selecting a field from the dropdown list or by using JSON
  • For the fields in your JSON expression, ensure they are not also selected from the dropdown list
  • You do not show your entire Create Work Item action so I cannot confirm this

[Gor Greyan]

Hi, @philip.song

Thanks for the question.

Try the following JSON.

{
{{#if(triggerIssue.customfield_15842)}}
"customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }
{{/}}
}

If the custom field isa  user picker, then the accountId should work, if it is a single select list type, then try value instead of accountID.

Let me know if it worked or not.

[philip.song]

Hi @Gor Greyan , 

Thanks for the speedy reply!

That seems to have worked, but caused something else strange.

This, as you provided, works:

{
"fields": {
{{#if(triggerIssue.customfield_15842)}}
"customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }
{{/}}
}
}

This also works:

{
"fields": {
"customfield_15851" : "{{triggerissue.customfield_15851}}"
}
}

However this errors:

{
"fields": {
{{#if(triggerIssue.customfield_15842)}}
"customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }
{{/}},
"customfield_15851" : "{{triggerissue.customfield_15851}}"
}
}

Error while parsing additional fields. Not valid JSON.

Do you know why this would be the case? Previously, I've chained together multiple fields, but there's something about this if statement for the customfield_15842 that seems to be causing issues

[Bill Sheboy]

Hi @philip.song 

It is the stray comma which is outside of the conditional expression, and so it appears before the section for customfield_15851 when the first field is null.  Please try moving it inside.

TIP: for dynamic JSON expressions, I recommend building them in a Created Variable and logging them before use in the rule action for create / edit work item.  That helps diagnose problems in the resulting JSON attempt.

Kind regards,
Bill

[philip.song]

Hi @Bill Sheboy , 

Sorry can you explain how you're meant to use the logger?

I built a variable here with the following logic:

{{#if(triggerIssue.customfield_15842)}} "customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }, {{/}}

And then used the `Log Action` component with the log message {{testvariable}}

but in the audit log, the log action simply says Log:

[Gor Greyan]

Hi @philip.song

Try the following JSON.

{
"fields": {
{{#if triggerIssue.customfield_15842}}
"customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }{{#if triggerissue.customfield_15851}},{{/if}}
{{/if}}
{{#if triggerissue.customfield_15851}}
"customfield_15851" : "{{triggerissue.customfield_15851}}"
{{/if}}
}
}

And regarding to loggin, no need to create variable, you can only put Log Action item, before the JSON, to see what it returns. On Log Action put the same JSON, and you will see the result, what JSON is returning.

Let me know if it worked or no.

[philip.song]

@Gor Greyan 

I see that's helpful! 

I tried your block (changing {{/if}} to {{/}} because it's otherwise invalid) and now the rule runs, but the fields don't populate as expected (all fields are empty).

[Gor Greyan]

Dear @philip.song

Thanks for your feedback.

Could you please share log action, before the action, to see the result.

[philip.song]

Hi @Gor Greyan , 

This is what I put into the log:

{ "fields": { {{#if triggerIssue.customfield_15842}} "customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }{{#if triggerissue.customfield_15851}},{{/}} {{/}} {{#if triggerissue.customfield_15851}} "customfield_15851" : "{{triggerissue.customfield_15851}}" {{/}} } }

and the result from the log is:

{ "fields": { } }

[Gor Greyan]

Hi @philip.song
This is the cleaned up version. Please try also this one.

{
"fields": {
{{#if triggerIssue.customfield_15842}}
"customfield_15842": { "id": "{{triggerIssue.customfield_15842.accountId}}" }{{#if triggerIssue.customfield_15851}},{{/if}}
{{/if}}
{{#if triggerIssue.customfield_15851}}
"customfield_15851": "{{triggerIssue.customfield_15851}}"
{{/if}}
}
}