Converting Groovy scripts to SIL

Converting scripts from Groovy to Simple Issue Language (SIL) can be 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 a tool like WorkFlow Pro - AI assistant for Jira.

Basic differences between Groovy and SIL

Import statements

Import statements in programming (lines 1-4 in the example Groovy script below) enable access to code from other modules or packages, making their functions, classes, and variables available in your program. Groovy depends heavily on these modules and packages, particularly Atlassian packages that provide the API to interact with the system.

SIL does not rely on import statements, so they can be deleted from the code. This eliminates time spent researching API documentation to determine which class files need to be imported or contain specific functionality.

Contents: 1 Basic differences between Groovy and SIL 1.1 Import statements 1.2 Class initialization 1.3 Issue initialization 1.4 Setting values 1.5 Function for storing issue data 1.6 Reindexing 1.7 Basic error handling 1.8 Type conversion 2 Best practices 2.1 SIL aliases 2.2 Troubleshooting

This approach also protects scripts from system updates that change imported class files. Since SIL scripts don't directly access these classes, they aren't affected by such changes. Instead, Power Scripts handles API class updates, allowing scripts to continue functioning normally after updates.

When using AI tools to convert Groovy scripts to SIL, remove import statements before starting the conversion process. Even though AI tools are trained on 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

SIL is designed to avoid direct use of Atlassian API classes, making it simpler to use. This approach makes SIL easier to use, protects scripts from class-level changes, and eliminates the class initialization step that Groovy requires (as shown in lines 12-13 of the example below).

While removing initialization code lines before AI conversion is optional, they should be deleted if the AI attempts to replicate this pattern in SIL.

Example 1

This Groovy script identifies projects where a specific Jira group is used in the project’s permission scheme, either directly or through a project role.

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.")
    }
}

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 particularly true when the script runs in the issue's context. This example shows the difference:

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

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

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 field values (shown in lines 12-13 in Example 2). AI conversion tools often incorrectly retain this Groovy pattern when converting to SIL.

This example shows the difference in setting values:

//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

The saveModifiedIssues() function in SIL (Cloud only) 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 automatically reindexes issues when changes are made, making Groovy's explicit reindex command (shown in line 17) unnecessary; it can be deleted.

Example 2

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

Basic error handling

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 ways that can cause code error and result in code 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

SIL is very flexible when it comes to type conversion; it handles most conversions automatically.

Example 3

This script validates a 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.

Best practices

SIL aliases

SIL includes a built-in feature called SIL aliases that simplifies managing custom field IDs in your code. 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() to write output to the console. These output messages are only visible in the SIL Manager or the SIL Runner Gadget and 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. To do this:

In SIL Manager, open the script you want to test.
From the Run menu, select Default Script Context.

The Run menu in SIL Manager
In the Script context configuration dialog window that opens, select a specific issue.

Script context configuration window
Click Run to test your script.
Use the script debugger for troubleshooting.