How to find all scripts using specific methods?

[Brian Peters]

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.

[Jamie Echlin _ScriptRunner - The Adaptavist Group_ · Accepted solution]

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 https://confluence.atlassian.com/jiracore/preparing-for-jira-9-0-1115661092.html#PreparingforJira9.0-api_changesAPIbreakingchanges.

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 https://library.adaptavist.com/ 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: https://docs.adaptavist.com/sr4js/latest/get-started/upgrade/upgrade-jira

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.

[Brian Peters]

Jamie,

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,

Brian

[Jamie Echlin _ScriptRunner - The Adaptavist Group_]

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

[Brian Peters]

Jamie,

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

[Jamie Echlin _ScriptRunner - The Adaptavist Group_]

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

[Peter-Dave Sheehan]

Hi @Jamie Echlin _ScriptRunner - The Adaptavist Group_ 

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.

[Brian Peters]

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

[Peter-Dave Sheehan]

Have you tried the script registry?

https://docs.adaptavist.com/sr4js/6.54.0/features/built-in-scripts/script-registry?utm_source=product-help

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)

[Brian Peters]

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.