Scripted field efficiency question (Script Runner)

Hi guys,

I use scripted fields (a lot) in our JIRA server instances (JIRA 6.2.5). A common occurrence is using scripted date fields from script runner (groovy), and then a third scripted field calculating the days between the two. I've noticed this can be somewhat problematic in search results unless I re-index often.

My general question is – let's say I have a goal in mind – in this case, a number of days between when a ticket moved between arbitrary statuses in a ticket. Is it better to create several scripted fields to calculate the datetime values for each status transition, plus another to compare them,  or a single scripted field that calculates the data it needs in memory, calculating the final result?

I know there are many ways to skin this cat – but my question is specifically re: script runner and best practices in general for scripted fields. 


2 answers

1 accepted

In theory it would be best to create one hidden field with some data structure that you can easily parse, such as JSON. Then the other fields would get that and display the bit of it they care about.

Again in theory, the value will be cached for the other fields that request it. But you can put some logging in your script and verify the field that does the grunt work is only called once.

In practice though the theory might be different, as they say. Try it though. IIRC some of us here have used that method and it's worked out ok.

Thanks Jamie -- and congrats btw with script runner being picked up by Adaptavist. I remember a while back saying I'd be happy to buy your plugin... and it looks like that is going to happen when we upgrade to Jira 7. :)

Congrats to Adaptavist on picking up me ;-)

1 vote

It should not really be a problem, but I've found basing one scripted field on the value of another seems to be an issue sometimes.  I suspect it's something to do with how the fields are called - the scripts run at indexing time, so I can understand that if scripted field A depends on a value for scripted field B, then if the code for field B is run after A, A could be using the old information.

I tend to avoid it in exactly the way you're thinking - even though you duplicate code, make A calculate what B will be instead of relying on B being first.

(I seem to remember Jamie's team are looking at libraries of reusable code so that you can write once and reuse, and they may get around this, but I'm not sure.  I've not actually been in the Adaptavist office for more than a few days in the last year, so I don't keep up with everything everyone is doing)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 29, 2018 in Marketplace Apps

How to set up an incident workflow from the VP of Engineering at Sentry

Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...

1,701 views 3 11
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you