How to convert custom calculated field to Scripted Field

[Christos Moysiadis]

Hello everyone,

Although i'm not quite sure if it is necessary. I have around 10 calculated fields that i want to convert them to Scripted Fields. Now they are 10 , later could be double or even more. 

Except this i see that there is something like ...!!!

AktivityNumber which is Text Field (single line) available in 2 projects shown in 1 screen &

AktivityNumber which is Calculated Text Field available Global  shown in 1 screen 

• Rhetorical question, Why not to have one Scripted Field ??????????

But i have legacy code with "<--@@Formula:  -->" annotation that I'm struggling to understand how it is working exactly and the make it as a script correctly!!!

Is there any good guide or something to help me with this one?

Thnx in advance

CM

[Nic Brough -Adaptavist- · Accepted solution]

Scripted fields are not native to Jira, you must be using an App to provide both the old and new ones.

The formula you've got suggests Jira Misc Custom Fields, I think.  I'm guessing by "scripted fields" you mean fields provided by ScriptRunner instead?

To convert between those two, you will need to read each of the calculations to work out what it is doing and then replicate the calculation in a scripted field.  You can't quite copy and paste because the misc fields use built in calls, whereas ScriptRunner uses the Jira API directly.

[Christos Moysiadis]

Hi @Nic Brough -Adaptavist-

As you mentioned, Jira Misc Custom Fields add-on is used and i want to use ScriptRunner instead. I'll have a look at your approach! 

But are there any significant differences between these two ways ? I mean pros and cons in using the Scriptrunner instead of Jira Misc Custom Fields and vice versa!

Thnx a lot for your time!

Kind regards

CM

[Nic Brough -Adaptavist-]

Yes, there are huge differences.  The misc custom fields provides a set of fields that do some pre-defined stuff for you, and some of them allow some scripting to be done within them, limited by what the field can get to.

ScriptRunner contains a load of "canned" stuff as well, things we've found people do a lot, but allows you direct access to the core of Jira's code, enabling you to write fields, functions, jql, services, listeners, rest end points, and even hack the ui in places.

[Akshay K V]

What can be the performance impact on the system due to the use of scripted fields? How will indexing be affected?

Limiting the context of the field can be helpful.

[Nic Brough -Adaptavist-]

Effectively, scripted fields run their code every time an issue is indexed.

If you write efficient code that does not try to do too much, you will not notice custom scripted fields being used.  If your code is poorly written or tries to do a huge amount, you will see a drag on performance during indexing (and this can be seen on the front end when users are doing things that cause indexing, like issue edits and transitions)

You are correct about the limited context - if a scripted field does not have context for an issue, then the script will not be run for updates on that issue.  I recommend always limiting scripted fields to the projects that they are needed in.

[Christos Moysiadis]

@Nic Brough -Adaptavist- i have 50k+ issues right now to my instance and of course it's growing.

Considering that i want to implement those 10 scripts to my instance i have some concerns about the re-index thing...

Except this, i notice that every time i access an issue which has the certain script to calculate the field in my instance the script runs in the background.

Now...With more than 200 developers in the company accessing the issues which have the other scripts running in the background in random times means that the performance will drop. Also the scripts are running again although its already once calculated.

I don't know how good is it to implement this change, just for the version control.

Best regards

CM

[Nic Brough -Adaptavist-]

 I said "you can think of scripts as running when the issues are indexed" earlier.  That is not strictly true, it's just the easiest way to think of it.

Some scripts will indeed run in other places.  (Behaviours will always run as people view/edit/transition issues for example)

Finding rogue scripts that have a significant impact can become a bit of an art.

However, with 10 scripts, 200 developers and 50,000 issues, I would not worry.  If you're running your Jira on the recommended hardware for that level (or better), it should be fine (barring a rogue script). 

I can't tell you who, but we have many clients running systems with 50,000 -> 250,000 issues, 500 developers and 50 scripts, no problem at all. 

[Christos Moysiadis]

@Nic Brough -Adaptavist- your support is more than appreciated!

thank you a lot

Kind regards

CM

[Jozef Vandenmooter]

@Nic Brough -Adaptavist- Even though I had already rolled out ScriptRunner, while I was gone, the shop I'm at acquired JMCF. I don't think that was necessary: as far as I can tell, everything that JMCF does can be accomplished by SR, maybe with a bit more coding in some cases. Are those correct statements?

Thanks,

Jozef  

[Christos Moysiadis]

Hello @Jozef Vandenmooter ,

my humble opinion is that you are correct! 

its almost 2 years since i wrote this ticket (when i was a noob Jira admin :P ) and now i see again my question and i understand even more.

After a quite a lot of scripting time for different use cases, I can personally tell you that i am a lover of SR. It's the first plugin that i will propose when i have a new customer, in case of easy or complex custom solutions. 

Of course JMCF is a cool tool because it is targeting to one thema. I worked with it and saw the capabilities. Yes ok approved, why not to have! But not my first choice.

From the other side SR gives you more options in different use cases. Listeners, Fields, Solutions in general out of the box, Behaviours, and the best of the best is the console :D

But again. The choice is relevant to many factors and the way an admin or a consultant is working.

Regards
Christos

[Jozef Vandenmooter]

@Christos Moysiadis Thanks for the info! Did you end up converting your JMCF Scripted Fields to SR Scripted Fields? 

Jozef    

[Nic Brough -Adaptavist-]

>everything that JMCF does can be accomplished by SR

Yes.

So, that's a horribly simple and blunt answer.  Despite being an Adaptavist with a direct interest in SR doing well, I try to be objective.  But SR can do everything JMCF does, and a lot more.

JMCF is great.  But it does what it does easily and with little fuss, it makes it easy.  The downside of SR is that you'll need to find or write code to do what you need.  While it is a load more flexible than JMCF, it has a lot less "click to configure".

You absolutely can replace JMCF with SR, but you will need to invest some time in doing it.

[Christos Moysiadis]

@Jozef Vandenmooter oh yes! of course i changed them. And i want also to thank @Nic Brough -Adaptavist- of his supporting replies. Thanks again (a lot) man and i hope i didnt frustrate you a lot up then :)

[Jozef Vandenmooter]

I created a JMCF scripted field that pulls a date from the Epic and placed it on the Epic's child issues. However, that has one major downside: you need a separate field for that. There's (understandably so) no way to edit a JMCF field on one issuetype and then have it calculated on another issuetype (I tried! :D ), even though you can narrow its context to certain issuetypes.

So, I'm looking at using SR to accomplish this. However, how can I keep the field in sync? A Behaviour does not run until an issue is touched. Will I have to use a post function to update all the child issues when the field is updated in the parent issue? Or can I use a SR scripted field to accomplish this?

[Nic Brough -Adaptavist-]

An SR scripted field is a calculation and a display-only field.  The easiest way to think of their timing is that they re-calculate their content when an issue is re-indexed.

A scripted field that pulls the Epic date down to its children sounds simple at first, but isn't.  You will need to place the field on all the issue types you want to see it on, and of course, include it in view screens, card layouts and so-on.  Then there's the edge-case - if you change the data on the Epic, you'll need to update all the stories that belong to it (the easiest trick - a listener that detects change of date on edit/transition, builds a list of the linked issues and simply kicks off a single issue re-index for each one.

[Jozef Vandenmooter]

Wasn't easy indeed. I used JSU's Copy Field from parent when an Epic child item is created, but then also had to write a Listener that updates all the child items in case the field is updated in the Epic.

And I had to add even more code to the Listener to cover the scenario where a child item is moved to another Epic!

What do you mean with "kick off a single issue re-index" though? Do I need to start a re-index from inside the Listener? Everything appears to work fine.

[Nic Brough -Adaptavist-]

If your script updates data outside the current issue, then scripts and calculations won't be updated outside it automatically. 

In many cases, it's fine, but you need to look at if your code affects other issues - Jira can't know if it needs to update the index if you don't tell it.