Scripted field efficiency question (Script Runner)

[Bryan Karsh]

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. 

Thanks!

[JamieA · Accepted solution]

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.

[Bryan Karsh]

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. :)

[JamieA]

Congrats to Adaptavist on picking up me ;-)

[Nic Brough -Adaptavist-]

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)