Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Using Assets in Jira Expressions

Jamie Echlin _ScriptRunner - The Adaptavist Group_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
February 20, 2024

A colleague mentioned a task he was doing as part of a DC->Cloud migration: In DC, their client had a condition whereby on a transition, the user had to pick from an Assets single picker custom field, called (let's say) "IT Asset Host". 

The tricky part is the user is required to add an attachment with the same name as the selected Asset name with the .png  extension, during the transition. We don't have the same powerful workflow functions as we do on DC - we need to write this rule as a Jira expression.

I used an in-development AI tool to give me a starter for ten on the Jira expression, which you can try yourself at .

To use the tool, first sign in to your instance, then give it a textual description of your condition. Finally, you need to give a sample issue key - it needs that to look up the names of any associated custom fields.

So my first attempt looked like:


Note - the:

 && == null 

corresponds to the requirement that the attachment be added this transition. Let's drop that aspect… it's incredibly annoying for the user if they happen to have already added the attachment before starting the transition. Not to mention it makes testing much harder. 

So, this is not a terrible attempt… to be fair I haven't given the tool any training on Assets custom fields, so can't really blame it for not getting it perfect on the first go.

Doing some testing though, nothing seemed to satisfy the condition.

When you have problems with expressions, it's a good idea to dig into the data you are getting, that is, look at how the data is presented to the expression. To do that, we can change the condition to the following, and press the re-test button:


This is interesting - the actual issue shows the custom field like this:

1YxfOewLTnUg1lKKwzRvABCltF4RgK_emCg1MATtPBZVoqLeyzQ1O4CayDSTq2oefSB3_IlBvcHswWmlNStryi-MHST0eFopIzKChw6Pl42HqmQ_4ueTkJMc-AhLTdSMGeTSyA26zXCYnVcm-LMkzcE (682×222)

So in the expression we don't get the name ("my other host") or any other attribute. Ideally we would just be able to load the object using

new Expression(issue.customfield_10312[0].objectId) 

in the same manner that you can load other data but that would be too easy. (Seriously, Atlassian could make this stuff a lot less faff).

Anyway… we can't load the asset object to get the name from an expression, nor can we use any REST API.

So we're in hacky workaround territory, might as well embrace it. 

As mentioned, you can load some data in Jira expressions, amongst them entity properties. So here's the strategy - we'll store a "map" or "dictionary" of asset object ID to name in some entity property. Doesn't really matter which property… I just chose the project associated with this workflow.

So the property we'll call KVP_List (don't ask), we'll put it on the JRA project, and it will look something like this:

  "5": "further host",
  "2": "my host",
  "3": "my other host",
  "4": "yet another host"

The list of assets is dynamic - we can't hard-code it. We'll generate this list using a ScriptRunner scheduled task… the script will use the Assets JSON API to execute an AQL query selecting all the objects that are shown in the custom field, and set the entity property to these ID-name pairs.

I set this task to run once an hour, in the absence of the ability to have it automatically run when the assets list is updated.

You can find this script at . Note the few variables you need to change, plus adding in an API token as a script variable.

Make sure you click Run Now unless you want to wait up to an hour for the script to run. Now, you can use the JSON API to verify the property was created successfully:

LPnDgzTNzn0Uhk_IUl8Z-7tERvP2m2ra3HJK-ZRqGMTEpbdFqrsoXJpjEJ3Qc8ZoM53IdkOH5tC53gCEOqqGLw28Hk64zmM1XIxhloEEMuP755JF_sajc2s3HfuZHekgNaW53a8BKpY5Fh2BX2x6vyw (837×301)

Looks good.

Finally on to your expression to be used in a ScriptRunner workflow validator.

You can find that here:

Make sure you change the project name to match the one you stored the property on, and the ID of the custom field. If you want to change KVP_List, then change it in both the sync script and the Jira expression.

If you're using the experimental expression generator, be sure to test with a couple of issues - one should fulfil the condition, one should reject, but neither should error out. It's common to write an expression that works in the positive sense, but errors out with a null reference expression when using on an issue that has no value for a custom field, or where that custom field is not in scope.

Finally, we can test the transition. With no attachment:

i5sbrr9bBX-kmqg5YSFbaddAQ4bTTI7VXIBCC5x4ZZNVd8nfKnR1h2RvLQMoie0h1CO4pSwf5eKvF6ijA2_kJtWFdcTGFf7pytjV-QTRLOIcCQ170ojq-e8M7aD1cv8-zdN5jYNCE3j3zdwgeepjb2M (749×155)

Then, when adding the correct png file, the validation passes and the transition can complete:

kKWNP0Omip0hYqi5IU0o6-MdV6aKWedyKjGbCUo36nP5PjYcgkqXpUxcrjKEVhZIIMAdDftlivAMt8ws38XEKaf2DcTj8WC0MYOHWaMBipq-47xdSGNrocRqAOytU50tIeR0rorPNGC46GfKA1Z-BI0 (760×235)

Give me a shout in the comments if you have any questions about using Assets and Jira expressions or ScriptRunner.

A few notes:

The size limit for entity properties is 32k - if your entities don't fit in to that, you'd have to dig even deeper by using multiple properties. This is already hacky, in for a penny…

Permissions - any user with Browse Project permissions can read the project properties. So this would not work if all project users were not allowed to view the complete list. The solution to that is for Atlassian to allow executing AQL and loading Assets objects inside expressions.

Note that when testing against an issue, the expression tester can return several possible states: green: expression ran successfully and returned true or false. Amber - expression was valid and ran successfully, but will always evaluate to false, because conditions need to return a boolean value - as noted above, this is to be expected when debugging why your expression won't work. Finally, red - there was an error - meaning the condition would not be allowed. Allowing conditions to fail to reject the condition seems like poor practice, as you can't use the execution history to spot real problems effectively.




Log in or Sign up to comment
AUG Leaders

Atlassian Community Events