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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to find all scripts using specific methods?

Is there a way to globally search for Scriptrunner scripts containing a specific word or phrase?  In this case I'm looking for some deprecated methods.

We have to upgrade to Jira 9.0 but there is a long list of methods that have been deprecated and removed from the 9.0 build, causing some of our Scriptrunner scripts to fail (our instance is too complicated to try testing each script's functionality).

I searched from the server command line for any files that contain one of the method names but found that unless it's in the "Script Editor" (and therefore a stand-alone .groovy file) there is no way to know where a found script lives (i.e. is it a behaviour, a listener, a job? If so, which one?).  Phrases unique to a single listener script returned multiple .class file hits with no indication of how they mapped to a script in the Scriptrunner interface.

Since Jira upgrades with deprecated/removed methods are not uncommon, I can't imagine I'm the first to run into this. 

Double bonus points if there's a way to search for the entire list of methods, rather than one at a time.

2 answers

1 accepted

0 votes
Answer accepted

Hey Brian,

there is a long list of methods that have been deprecated and removed from the 9.0 build

Yep, for other people that list is at

But truth be told, the number of methods people are likely to be using in their scripts is very small.

We made the required changes to the plugin, to the documentation examples, and to all the scripts on and the number of files we had to change were about 10... and they were all usages of `UserUtil` except one `JiraUtils`.

For major Jira upgrades we have a special documentation page that describes probable changes for script authors and what to change them to, but that page is delayed - I'll update here when released. However most of what we said about upgrading 7->8 is relevant:

As Peter-Dave said, the script registry should help you. If you upgrade a non-production copy of your production instance (you are probably doing this anyway as part of your upgrade procedure), then go to Script Registry, in Jira 9 the removed methods will be marked in red. 

In your production Jira 8 instance, you should see warnings for the methods that will be removed, as AFAIK all removed methods have been deprecated at least since Jira 8.

We know that not everyone upgrades and tests with a non-production instance first, so we have been trying to find ways to let people know they are using code that will not work in the next major host version.

So from the next version (6.55, which should be released on Weds 11th July), the editor will show an additional warning for those methods that will be removed in Jira 9, on Jira 8. This will generally have a deprecation warning alongside.


These warnings will also be shown for file paths in the script registry. 

We toyed with making these errors rather than warnings but felt it would be too noisy. The other option we may look at is adding an "upgrade mode" to script registry, where this would be an error and not a warning. If you combine that with the new toggle which allows you to filter on only those scripts with errors it should be relatively easy to find them.

Let us know what you think would be helpful.


Thanks for replying.  We probably upgrade more frequently than most (security concerns) and at times the process has been pretty painful.  So, I'm glad to hear that you're working to improve things. 

You're right, ultimately it turned out only about 10 scripts were affected. However with ~1,400 scripts and 94 removed items for this release, just putting together that short list required two entire days: One to lazy load the script registry then another day to CTRL+F the 90+ search terms and manually record the names of the affected scripts (and those two days just told me which scripts I will have to re-code).  If we'd had 50 affected scripts, I'd still be working on it, haha. 

With the v9.0 improvements you describe, having scripts aware of what items will be removed is definitely an excellent step forward.  However, picking through hundreds of individual scripts or relying on the slowness of the script registry interface is an issue.

A suggestion: For our purposes, loading the scripts all on the registry page isn't particularly useful since I won't be editing the scripts on that page anyway.  Ultimately all we need is a simple list: scripts that need attention (and where they live) + the removed items in those scripts (bonus points if alternatives or a link to the API doc for those removed items is displayed, double bonus if deprecated items could be toggled as well).  Something like this could be run in the background while other work continues, rather than the days-long scroll/load/scroll/load/scroll/load/Ctrl+F/Ctrl+F/Ctrl+F/Ctrl+F/Ctrl+F/ marathon. 

Something like a "Scripts Affected By Upgrading" page with just a dropdown to select which upgrade you're migrating to and a go button that then lists affected scripts and their soon-to-be removed/deprecated items seems ideal (at least without me thinking super deeply about it). If it takes a while, running it in a separate browser tab while I do other work sounds ideal.

However, all in all, very glad to hear that you all are working to make it easier.

Thank you,


Like # people like this

Sounds like you have been having a torrid time, we're sorry about that.

Just a few points:

We probably upgrade more frequently than most (security concerns)

What we're talking about here only affects Jira major versions, ie 6 to 7, 7 to 8, 8 to 9 etc. I guess you upgrade early but everyone does these jumps unless they skip a major version, which I don't think should be entertained seriously as an idea.

Also, and excuse me if it sounds like I'm talking out of turn, but for others, imho the way to mitigate security concerns is to stay on the latest LTS release and upgrade frequently on the LTS track, rather than making a major version jump. I don't think that's any more secure that being on an LTS version. But each organisation has their own policies...

just putting together that short list required two entire days

I would recommend looking for the deprecation warnings (amber warnings in the script registry and editor). I completely appreciate this is not straightforward if it's slow to load, or if you also have false positive errors (eg using dynamically-typed code that we can't properly type-check). I'd do this rather than checking every single removed method, the vast majority of which there's a vanishly small chance of anyone using.

A suggestion: For our purposes, loading the scripts all on the registry page isn't particularly useful since I won't be editing the scripts on that page anyway

No indeed, but everything there has a link to where it can be edited, so you could open the affected ones in a new tab and edit there.

> Something like a "Scripts Affected By Upgrading" page with just a dropdown to select which upgrade you're migrating to and a go button that then lists affected scripts and their soon-to-be removed/deprecated items seems ideal

I think something like this is the way we will go. We have discussed an approach along these lines, really what we are putting out on Weds is just a start to help early movers to Jira 9. There will be more to come hopefully.

Also note that the mouseover should show documentation for the method/field which has the information of what it should be changed to.

I can't really guarantee it will be much faster though - to get this information we need to recompile every script... I wonder if there is a memory issue on your instance because it should not be so slow.

We appreciate your feedback a lot.

cheers, jamie

Like Jonny Carter likes this


Wednesday's changes definitely sound like an improvement.  I appreciate what you all are doing to help us out here.

Honestly, I don't know the details of our security policy beyond that we seem to upgrade to whatever the latest version is an awful lot, haha.

I think our infrastructure team might have upgraded memory the day after I ran the registry (excellent timing, haha).  I may be wrong but the page's behavior makes me think javascript lazy loading may be the culprit.  Rather than starting the script registry page then going off to do another task while it loads itself, I have to manually scroll the page every few seconds in order for all the scripts to appear so that I can finally CTRL+F.  In other words, even with ample memory resources, it would still take a long time to get all the scripts to show in the UI because we have a ridiculous number of scripts (at least in our staging instance).  Hopefully I can take advantage of the upcoming changes next time.

Either way, I have what I need for now, thank you very much for your assistance and continued work.

- Brian


Hey Brian,

This is probably detail you don't want to to know but just in case.

The compilation happens server-side, when the script registry page loads it gets this information for each script, in batches of 5, to avoid putting too much load on the server.

Separately, displaying hundreds or thousands of editor instances on the screen can make the browser sluggish. So it only loads editors for the ones that are actually visible. But we know people use browser find, so scripts that are not currently visible are displayed in simple text areas, so browser find works... at least it did in all our testing.

When it's scrolled into view the real read-only editor is shown.

Truth be told the script registry is overdue for a re-imagining.

Glad you got there in the end anyway,

cheers, jamie

Hi @Jamie Echlin _Adaptavist_ 

A suggestion for the script registry...

Provide an option (before running the script) to only include in-line scripts.

Most people that have scripts stored in files will be able to easily search either with their IDE or the OS filesystem to find specific strings.

The registry becomes necessary in this case only to search for those inline scripts.

So I don't have to scroll to get the thing the fully load?  That's actually good to know, thank!

1 vote

Have you tried the script registry?

This will expose all your scripts, inline as well as script files.

If you have a lot, the UI can be a little slow.

But I use it all the time just for that purpose.

I just use the browser find in page function to search for any string.

You just have to repeat for each of the large categories of scripts (workflows, behaviours, listeners etc)

Thank you for the suggestion, while it was extremely slow, I did end up using the script registry to build my list of scripts that need attention.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events