split() - Smart value from field not splitting correctly

[Tyler Giles]

I have a custom field that contains first and last name:

"displayName": "John Doe",

If I do either of these-

{{issue.fields.customfield_10173.displayName.split(" ").get(0)}}
{{issue.fields.customfield_10173.displayName.split(" ").first}}

It will return John, Doe

I want just John

What am I doing wrong? Thank you!

[Tyler Giles · Accepted solution]

Ok, I figured it out. Because my customfield_10173 is originally a list of names, whether or not one or multiple are added, I had to do as follows:

{{issue.fields.customfield_10173.displayName.first.split(" ").get(0)}}

.first selects the first name of the list and then I can split up that name. Even if it's only one name to begin with.

Thank you so much @Bill Sheboy and @Duc Thang TRAN for assisting me!

[Duc Thang TRAN]

Hello @Tyler Giles 

If you want to get only John for John Doe 

I can suggest you this smart value  

{{issue.fields.customfield_10173.displayName.split(" ").first}}

[Tyler Giles]

@Duc Thang TRAN  Sadly, this does not appear to be working:

[Duc Thang TRAN]

It strange, work perfectly for me 

[Tyler Giles]

@Duc Thang TRAN Thank you for the assistance Duc! Can you do my a huge favor and  see what this returns for you:

{{issue.fields.customfield_10049.displayName.split(" ")}}

I am interested in seeing what a just a split will return vs what I am seeing. I see:

[John, Doe] or [Jira, Integration]

For troubleshooting purposes, I am interested to see if yours returns:

[Duc, Thang, TRAN] or something else.

Thank you for your time!

[Bill Sheboy]

Hi @Tyler Giles 

First, and guessing the field type is user select, perhaps try writing this to the audit log to observe what it returns:

display name for selection: {{issue.customfield_10173.value.displayName}}

first name for selection: {{issue.customfield_10173.value.displayName.split(" ").get(0)}}

If that does not help, please answer the following:

• What is the type of your field: user selection, text, something else?
• What type of project are you using: company-managed, or team-managed?
• And if team-managed, where was the custom field defined: at the global context or within the team-managed project?

Kind regards,
Bill

[Tyler Giles]

@Bill Sheboy --Will try! I am brand new to Atlassian, but not to software development or ITSM in general.

How exactly can I "try writing this to the audit log to observe what it returns"?

I have heard others mention this and I have been looking for documentation on how to do so. Right now, I am trying to familiarize myself with all of the smart values that I will need for my project, and to test returning values, I just have an automation that is emailing me per every issue opened.

So I am opening up a brand new test issue every time. If there is a way to test these without opening a new test issue, I am all ears! Thank you so much for your time!

[Bill Sheboy]

There is a Log Action which allows writing information to the audit log for debugging / informational purposes: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Log-action

If you add that action in your rule, you may paste in the expression, run the rule, and review the audit log details to see what happens.  You may add multiple log actions, at different points in the rule, when trying to assess progress.

Regarding your question about testing issue date, some tips are...

• Please note well: some rule testing can consume "usage limits".  As you are on a Standard license, consider only writing to the audit log during testing, rather than editing issues, to help manage that.  To learn more about your limits, and what counts / does not count, please look here: https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/#What-are-my-usage-limits
• With complex / risky rules, consider creating a test project specifically for rule experiments.  When it works as needed, you may copy or re-assign it to the correct project from the global rule settings.  This test project may also act as a library of rules for reuse later.
• In some cases, such as rules triggered on Issue Created, you may not want to repeatedly create new issues in the project.  A workaround for that is:
  • Remove the current rule trigger of Issue Created, replacing with the Scheduled Trigger.  This trigger allows manually executing the rule from the ... menu as often as needed.
  • In the Scheduled Trigger, add JQL for your test issue's key.  For example:
    • key = TEST-123
  • Test and improve your rule...
  • When done, replace the Scheduled Trigger with Issue Created again
  • Test one last time, and then claim victory :^)

[Tyler Giles]

@Bill Sheboy Ok, I found out how to manual trigger to the log, this is huge!

The removal of .fields and the addition of .value seem to not be returning any data. Please see screenshot of my returns:

[Tyler Giles]

@Bill Sheboy I am assuming that this is a user selection field, as the request form only accepts users that we have in our JSM.

[Bill Sheboy]

Before anything else, I recommend pausing to identify the type of field in the global custom field list, and its scope (i.e., JSM, Jira, both).  That will clarify how to access its attributes in the rule.

[Tyler Giles]

This custom field type is a User Picker:



This seems to be defined outside of my current project, as it appears it can be assigned to multiple projects.

[Bill Sheboy]

The key here is it is a multiple-select, user field.

And so the specifics of how you want to use the information will determine how to proceed:

• iterate over the selected values; or
• select one specific, selected value, and then parse the name into first and last.