Page Comparison

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.

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

Example 1

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

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

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.

Type conversion

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

Example 3

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


CustomFieldManager cfm = ComponentAccessor.getCustomFieldManager();
CustomField templateCF = cfm.getCustomFieldObject(10112L);
log.error('[LOG] templateCF: ' + templateCF)

Map templateValue = issue.getCustomFieldValue(templateCF)
log.error('[LOG] templateValue: ' + templateValue)

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

if (templateIsEmpty) {
    log.error("Template is empty")
    return false;
}

log.error("Template is not empty")
return true;

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 from 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 log output messages are helpful for understanding script execution and debugging.

Debugging/Run Configuration

Using the run configuration setting, the The SIL Manager can be configured to test scripts as if they were being triggered by a specific issue. Combined with the script debugger, this is a very useful tool for troubleshooting scripts.

By defining the script context when running scripts in SIL Manager, you can test scripts as if they were triggered by a specific issue. When used with the script debugger, this feature becomes a powerful tool for troubleshooting.