Page Comparison

Migrating from a language like groovy to a language like Converting scripts from Groovy to Simple Issue Language (SIL) can be challenging for some users since the SIL language has been simplified so that it does not require many of the steps used in groovy code. Here are some common steps that can be helpful in preparing a groovy script simpler than expected, as SIL has been simplified and requires fewer programming steps than used in Groovy code. This page presents a few key concepts and steps to help prepare Groovy scripts for conversion, especially when using an AI a tool like WorkFlow Pro - AI assistant for Jira.

Basic differences between

groovy

Groovy and SIL

Import statements

With scripting/programming, import statements Import statements in programming (lines 1-4 from in the example groovy Groovy script shown below) are used enable access to bring in code from other modules or packages, allowing you to use making their functions, classes, and variables available in your current program. The groovy language relies Groovy depends heavily on these other modules or packages which are usually and packages, particularly Atlassian packages that provide the API to interact with the system.

The SIL language does not rely on import statements in the code and therefore , so they can simply be deleted from the code. This saves a lot of time that is normally spent research API documentation about eliminates time spent researching API documentation to determine which class files need to be imported or which class file contains a contain specific functionality.

Contents:

Table of Contents

minLevel	1
maxLevel	3
outline	false
style	default
type	list
printable	true

This

also guards users against system updates since it is the

approach also protects scripts from system updates that change imported class files

that are changed with version updates

. Since SIL scripts

do not access the classes directly they are not impacted by those

don't directly access these classes, they aren't affected by such changes. Instead,

the

Power Scripts

application is updated to use the proper

handles API class

. Once updated

updates,

the

allowing scripts

will continue to function as normal

to continue functioning normally after updates.

info

Tip

If

When using

something like

AI tools to

migrate groovy

convert Groovy scripts to SIL

it is recommended to delete the

, remove import statements before

asking AI to perform

starting the conversion process.

Despite the AI being

Even though AI tools are trained on

the SIL language it has a habit of trying to closely follow patterns found in the groovy script and replicate those patterns in SIL. The AI can get confused when those patterns are not supposed to

SIL, they tend to replicate Groovy patterns in their output. Removing imports prevents the AI from attempting to reproduce patterns that shouldn't exist in SIL.

Class initialization

The Simple Issue Language was designed to be as simple as possible and so it avoids directly using the classes from the Atlassian API directly. This

SIL is designed to avoid direct use of Atlassian API classes, making it simpler to use. This approach makes SIL easier to use

and also

, protects scripts from

changes within those classes. It also removes the step that is usually required in groovy to initialize those classes like can be seen

class-level changes, and eliminates the class initialization step that Groovy requires (as shown in lines 12-13

in

of the example

groovy script shown It is not always necessary to remove these

below).

Info

While removing initialization code lines

prior to submitting to the

before AI

for

conversion

. However,

is optional, they should be deleted if the AI

tries

attempts to replicate this pattern in SIL

then they should be removed

.

Example

#1

1

Expand

title	Example Groovy Script

#1

1

This

groovy

Groovy script

will find all

identifies projects where a specific Jira group is used

by a project, through its permission scheme. A group is being deemed as being used by a project, where it's used by its permission scheme,

in the project’s permission scheme, either directly or through a project role.

Code Block

import com.atlassian.confluence.user.DisabledUserManager
import com.atlassian.crowd.embedded.api.CrowdService
import com.atlassian.sal.api.component.ComponentLocator
import com.onresolve.scriptrunner.parameters.annotation.ShortTextInput

@ShortTextInput(label = "Users", description = "Type usernames of deactivated users you would like to reactivate, seperated by spaces")
String names
assert names

def disabledUsers = names.split()

def disabledUserManager = ComponentLocator.getComponent(DisabledUserManager)
def crowdService = ComponentLocator.getComponent(CrowdService)

disabledUsers.each { userName ->
    def user = crowdService.getUser(userName)
    if (user) {
        if (disabledUserManager.isDisabled(user)) {
            disabledUserManager.enableUser(user)
            log.info("User $user.name has been enabled")
        } else {
            log.info("User $user.name is not disabled")
        }
    } else {
        log.debug("User $userName was not found.")
    }
}

Initializing the issue

Similar to initializing classes, it is not required in SIL to initialize the issue so that it is editable (line 7 in the example groovy script

Issue initialization

In SIL, you don't need to initialize an issue to make it editable, unlike Groovy, which requires this initialization step (shown in line 7 in Example 2 below). This is

especially

particularly true

if

when the script

is running

runs in the

context of the issue.

issue's context. This example shows the difference:

Code Block
//

groovy

Groovy approach
def issue = Issues.getByKey('SR-1') as MutableIssue

//SIL approach
string key = "SR-1";

Functions for setting values

In the SIL language it is also not required to use

Groovy gets the issue and makes it editable (MutableIssue); SIL simply stores the issue key as a string.

Setting values

Unlike Groovy, SIL doesn't require a function to set

the value of

field values (

see

shown in lines 12-13 in Example 2).

This is a common mistake that AI will often make when trying to convert groovy to SIL.

AI conversion tools often incorrectly retain this Groovy pattern when converting to SIL.

This example shows the difference in setting values:

Code Block
//

groovy

Groovy approach
setPriority('Highest')

//SIL approach
priority = "Highest";

Groovy uses a function call (setPriority) and takes the priority as a parameter; SIL uses direct assignment and treats priority like a regular variable.

Function for storing issue data

While SIL does have a function for storing issues data,

The saveModifiedIssues() function in SIL (

cloud

Cloud only)

, this function is used for optimizing memory usage and is not required at all. The groovy code on line 16 could be completely removed. With SIL, all changes will be committed

serves for memory optimization, not for saving changes; it's not required for storing issue data. Unlike Groovy's explicit save operation (shown in line 16 in Example 2), SIL automatically commits all changes when the script completes.

Reindexing

SIL

scripts will automatically reindex the issue if there are changes. The groovy code on line 17 is not required and

automatically reindexes issues when changes are made, making Groovy's explicit reindex command (shown in line 17) unnecessary; it can be deleted.

Example

#2

2

Expand

title	Example Groovy Script

#2

2

This script

can be useful for bulk changing issues, without sending emails, or affecting the last update time of the issue. No record of the change will appear in the change history either

performs bulk issue updates without triggering emails, modifying last update times, or creating change history records.

Code Block

import com.adaptavist.hapi.jira.issues.Issues
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.index.IssueIndexingParams
import com.atlassian.jira.issue.index.IssueIndexingService

def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)

def issue = Issues.getByKey('SR-1') as MutableIssue

issue.set {
    setPriority('Highest')
    setSummary('my new summary')
}

issue.store()
issueIndexingService.reIndex(issue, IssueIndexingParams.INDEX_ISSUE_ONLY)

Basic error handling

One of the ways that the SIL language was simplified to reduce the code the user must write is by taking care of common coding tasks automatically. Within most functions in the SIL language are steps on how the code should react if the data

SIL simplifies coding by automating common tasks. Most functions in SIL come with built-in protection against data that is null, missing, or invalid in

a way

ways that can cause

an

code error

resulting

and result in

the

code

crashing. Since this basic error handling is already built in it is not required that the user include it in the SIL script so lines 15-21 could be removed from the example below. InfoSIL does have error handling ability and some functions will throw specific error types. This is done so that the user can have options on how the script should perform when it encounters the error

crashes. This makes Groovy's explicit error handling (as shown in lines 15-21 in Example 3 below) unnecessary in SIL.

SIL provides error-handling capabilities and can throw specific error types, giving you control over how scripts handle errors.

Type conversion

The

SIL

language

is very

lenient

flexible when it comes to type conversion

and will handle

; it handles most conversions automatically.

Example

#3

3

Expand

title	Example Groovy Script

#3

3

Setting

This script validates a

template field as mandatory

custom template field, returning false if no template is selected and true if a template value exists. It logs the validation status through error messages.

Code Block

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.CustomFieldManager


CustomFieldManager cfm = ComponentAccessor.getCustomFieldManager();
CustomField

tempalteCF

templateCF = cfm.getCustomFieldObject(10112L);
log.error('[LOG]

tempalteCF

templateCF: ' +

tempalteCF

templateCF)

Map templateValue = issue.getCustomFieldValue(

tempalteCF

templateCF)
log.error('[LOG] templateValue: ' + templateValue)

boolean templateIsEmpty = templateValue.get("SELECTED_TEMPLATE") == null;

if (templateIsEmpty) {
    log.error("

Tempalte

Template is empty")
    return false;
}

log.error("

Tempalte

Template is not empty")
return true;

Tips and tricks

Best practices

SIL aliases

The

SIL

language has

includes a built-in feature called SIL aliases

which helps manage the use of

that simplifies managing custom field

id’s

IDs in

the

your code

and makes for easier reading of the code and easier migrations. It is a good idea to switch to using aliases when converting a groovy script

. Using aliases makes code more readable and migrations easier, making it a good practice when converting from Groovy to SIL.

Troubleshooting

runnerLog()

When writing scripts in the SIL Manager, you can use a special function called runnerLog()

can be used

to write output to the console. These output messages are only visible

from

in the SIL Manager or the SIL Runner Gadget and

are perfectly safe to leave in the code even if they are intended to run elsewhere like a post function.

These messages are very helpful for understanding what is happening within the script and for debugging.

Debugging/Run Configuration

Using the run configuration setting, the SIL Manager can be configured to test scripts as if they were being

can safely remain in your code, even when scripts run elsewhere (such as post functions).

The output messages are helpful for understanding script execution and debugging.

Run and debug scripts

To test and troubleshoot scripts, you can run them as if they were triggered by a specific issue.

Combined with the script debugger this is a very useful tool for troubleshooting scripts.

Contents:

Table of ContentsminLevel1maxLevel2outlinefalsestylenonetypelistprintabletrue

To do this:

In SIL Manager, open the script you want to test.
From the Run menu, select Default Script Context.
Image Added
In the Script context configuration dialog window that opens, select a specific issue.
Image Added
Click Run to test your script.
Use the script debugger for troubleshooting.

Versions Compared

Old Version 6

New Version Current

Key

Basic differences between

Groovy and SIL

Import statements

Class initialization

Example

1

Initializing the issue

Issue initialization

Functions for setting values

Setting values

Function for storing issue data

Reindexing

Example

2

Basic error handling

Type conversion

Example

3

Best practices

SIL aliases

Troubleshooting

runnerLog()

Debugging/Run Configuration

Run and debug scripts