Store smart values in Assets and expand in automation rule

[Charlie Misonne]

Hello dear Atlassian Community,

I want to make my Jira automation rules more dynamic by storing smart values in Assets. I don't think it can be done but I'd like your insights about this idea.

Let's say I have an Object Type with several objects. Each object has a text area attribute called "template".
A template can be something like:

Reporter: {{issue.reporter}}

Information:
{{issue.key}}
{{issue.customfield_12345}}
{{issue.customfield_67890}}

There is an automation rule that fetches 1 asset with object lookup. The rule edits the issue's description by using {{lookupObjects.template}}.

The goal is to have to expand the smart values (= have their actual values in the description).

When I try it the description contains the exact string with curly braces, not expanding the variables.

Any ideas?

[Wouter van den Berg]

Hi @Charlie Misonne

I don't understand your use-case here. You want to update a description field in a Jira issue with values taken from an object that are related to the issue? 

Why would you store issue.key and other issue related customfields in an Object? Have an Automation rule take that template information and repost this in the description of the issue. There are far easier ways around this without the use of assets. 

I can imagine you could want certain information posted back into objects from issues but again there are standard features for this. 

Could you elaborate a bit more so we can understand your reasoning and what you are looking for? 

[Charlie Misonne]

Hi Wouter,

Let me try to explain:

Let's say I have 20 objects in a certain assets ObjectType. When issues are created the user selects one of the 20 objects with an assets custom field.

An automation rule updates the description of the ticket with a certain template. The template is different for each of the 20 objects.
(after the description update other rules are triggered such as the creation of sub-task. So it's really not about the description only but I'm leaving out that part for simplicity).

I don't wat to have 20 if/else branches in an automation rule for this. That's why it would be nice to store the "template" in the objects at the assets level.
I tried it but it does not work so I guess I'm stuck with the if/else anyway.

[Wouter van den Berg]

Hi @Charlie Misonne, 

I still don't understand why you want to store data that should be coming from an issue, inside an object. Only for the reason that you don't want 20 if/else branches.

When you fetch your information from an object that doesn't mean your description inside your issue knows what data to put there as you actually need to refetch that data from the issue again, even if it's the exact ID you are targeting. I tried a couple of ways but they all end the same way as a string value inside some field or in the description. API would be an option but this is limited to only a few types of customfields. https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields/#api-rest-api-3-field-post if your customfield types are there then you could add the id's to your object (without customfield_), use that ID to send your webrequest and then use the webresponse to edit your issue. 

You can also take this a step further and have some expressions stripping text and replacing it elsewhere but I do believe this will result in a string with the customfield id in it. I understand you want to outsmart Jira and keep it simple but your approach makes it unnecessarily complicated. Looking at what you want to obtain I can only say that the best way forward is to think about the logic of creation of that ticket and then applying it with appropriate. In your case I am thinking that for some issues some customfield is filled and other customfields are not. With appropriate if/else you can simply use the edit Description to put all of your data in there. If the field is not filled it won't be added. 

Doing an API call to retrieve all of the issue's data and then manipulating the webresponse to output the description is an option too but that's a whole different level of complexity. 

I'd love to help you out but without any detailed information and context I am just making assumptions on your reasons. I would do this with branching. 

[Chad McCormick]

@Charlie Misonne did you get this working? I'm attempting to do precisely this and for the same reason - to have the resultant message be driven by a template that leverages smart values and is stored in an asset field where it could be updated without having to update the automation that fetches and applies it.

[Charlie Misonne]

Hi Chad,

No I wasn't. I don't think it is possible at all.

[Remy]

Also trying to do this Lol. I guess I will be delving into automation lookup tables again.