Can a custom text field default resolve smart values?

[Phil Bustin]

I think the answer is no:

Default value

Field appearance in screen

[Bill Sheboy · Accepted solution]

Hi @Phil Bustin 

That is an interesting idea, and I also expect the answer is "no"...and...

A work-around could be to use some token/keyword other than smart values, and on issue create (edit, etc.), trigger a rule to parse the field and substitute in the smart values just-in-time.

Kind regards,
Bill

[Phil Bustin]

I'm trying to understand:

1) Why parse, when I could just insert the lines I want in the automation?  In fact, the field doesn't need a default if every issue create populates it.

2) Are you saying that in any issue, even if the user leaves the issue and then returns, the lines I placed in the field will hold?  Makes sense.

3) Alternatively, is there any event such as opening an issue before it is transitioned that could trigger the automation?

[Bill Sheboy]

Hi, Phil. 

Sorry if I misunderstood your scenario...I got the impression you were trying to create default field values and then have them just-in-time filled in dynamically at issue create.  That is why I suggested the tokenization technique.  You are correct that you could just have the rule do this at issue-create.

I seem to recall that rules could not directly trigger workflow actions, but that there were work-arounds involving setting fields values, which would then trigger rules.

[Phil Bustin]

That sounds interesting.  Since I've got my workaround, I'll defer learning about that until later.

I must have replied to the wrong post, or not clicked 'Publish', because I don't see it on this one; at any rate, here it is now: The automation worked.

[Phil Bustin]

Today, when a different user (that I made a member of the administrators group and administrators role) created the issue, the text did not appear when the transition was clicked (although the automation log says the field was edited.)

When I then created an issue, the edit worked.

[Bill Sheboy]

Would you please post images of the current rule and audit log details showing that execution?  Thanks!

[Phil Bustin]

Automation log when other user created an issue:

Automation log when I created an issue:

[Bill Sheboy]

Does this always work for you and fail to make the edit for the other user?

Well, it does not appear to be permissions-related as something in the rule would fail otherwise.

I wonder if this was a timing issue; the issue created trigger can fire faster than the data is available, and so perhaps there is some collision happening.  Although the conditions passed, so perhaps not.

Please try adding a Re-fetch Issue action immediately after the trigger to see the impact.

[Phil Bustin]

What is a Re-fetch issue action, please?

[Bill Sheboy]

It is a rule action to reload the data for a trigger issue: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Re-fetch-issue-data

[Phil Bustin]

That appeared to work.  Thanks!

[Phil Bustin]

Today, the Ask the community function spins indefinitely, so I'm updating this thread instead.

I have an automation that populates a text field that includes {{customfield.10274}}, and the smartvalue was working at one time, as I recall.  It is not working today.

Atlassian documentation lists:

Available properties
{{issue.[Custom Field].id}} - Returns the unique id for the field assigned by Jira. It is better to use this than name as it cannot be changed.

But that seems to contradict itself, since [Custom Field] is presumably the name of the field, and anyway, I don't want the number--just the value.  Also, should I use {{issue.customfield.10274}} instead of {{customfield.10274}}?

In the automation, as a test, just before I set the value of the text field, I set the value of the customfield, but {{customfield.10274}} just appears as space.

[Phil Bustin]

Also, when I tried using {{#debug}} in front of the text string, I got an error :

Failed to close 'debug' tag: {{#debug}} ***

[Phil Bustin]

This worked: {{issue."To Region"}}

[Bill Sheboy]

Hi @Phil Bustin 

I think the syntax is an underscore and not a period for custom fields.  Like this:

{{issue.customfield_10274}}

And when in doubt of a smart value for a field, you can also use the how-to article below.  Smart values are name, spacing, and case-sensitive, so it can be tricky figuring out what is used for a specific field without checking.  And if you do not find your field with this method, that is usually an indication it is not supported by the REST API (or automation rules).

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Phil Bustin]

I'm extremely interested now in trying the token idea you raised.  In addition to the field appearing blank when I run the transition in an issue the day after I tested the issue, the date and time is from when the transition ran that triggered the automation last ran--could be days before the transition runs that shows the field.

So far, I can't find documentation on this.

[Phil Bustin]

The only workaround I can think of, besides the user having to manually enter the date and time twice in the field, is to have the user trigger an automation manually before running the transition.

[Bill Sheboy]

To clarify, are you observing that {{now}} does not equal the actual "now" of when the rule triggers?

[Phil Bustin]

The big issue is that I can only run an automation to resolve date and time when some other transition runs, so (of course) the action is useless (because the goal is to populate the field with the current date and time).

A secondary problem is that the time seems to be 4 hours later than the current time, but I'd have to double-check that.  It's irrelevant unless there is a way for me to populate date/time when the transition screen appears.  Atlassian hasn't apparently seen fit to enable that. 

[Bill Sheboy]

Gotcha...and I am stumped on how to solve that part.

You might want to also search in the developer community for ideas around the transition screen: https://community.developer.atlassian.com/

[Phil Bustin]

Thanks.  What about your idea of using tokens in the field default?

[Bill Sheboy]

The key with that one is does the automation rule trigger when you want?  If it does, you can put a token value (e.g., REPLACE_WITH_NOW) in the default and then let the rule trigger and replace the token with {{now}}

[Phil Bustin]

What do I select as the automation trigger?  I guess there is no trigger.

[Phil Bustin]

I don't suppose there are forms and a form load trigger available in Jira Work Management?

[Bill Sheboy]

I do not believe there is a trigger for forms/form save yet.  I was thinking your workflow was altering an issue field in a way that could be detected...and so trigger a rule.  I seem to remember seeing a posting about that as a work-around.

[Phil Bustin]

My workaround is this:

I instruct the Developers, who are used to seeing a Begin and End banner pre-inserted into the field from the app they are currently using, to NOT expect to see the banners, but to expect them to be inserted once the transition is completed.

The transition-triggered automation edits the field, concatenating the Begin banner, blank line, field contents, blank line, End banner and blank line.

Everyone goes home happy, and the Developers can be reminded in the Developers Guide I created for them that Jira Software needs a pre-transition trigger enhancement.