One of the main benefits of SIL is, that scripts are portable across instances and hosting types. This is possible because the SIL language was created to run at a higher level then a general programming language. It was built to be similar to a domain specific language that simplifies the scripting process. The language attempts to remove the unnecessary complexity of the technical implementation details without removing the power of a scripting solution. So if you wrote a SIL script in an older version, it will work in any future version, and you can migrate your script from Server to DC to the cloud without having to rewrite any scripts.

We place a lot of importance on the ability to migrate scripts from older versions of Jira to new versions without requiring any changes or modifications to the scripts. It is one of the main reasons that Power Scripts uses a simple to use JavaScript like scripting language called SIL (Simple Issue Language) and not a Java based language that has been mostly been abandoned by the development community.

Did you know that this works with the Cloud as well?

The SIL language is mostly identical between on-premises versions of Jira and the Cloud.

What is different?

Minor function (function) differences

Since the SIL language depends on the Jira API, differences between the server/data-center APIs and the cloud APIs can subsequently impact the SIL functions. Even though most of the Atlassian APIs are similar between hosting types, there are occasional differences, as shown in the example below.

For example, when adding a comment on the on-prem version, you can set the visibility of that comment to a group or a project role. On the cloud, you can only use a project role.

Of the 700 Power Scripts cloud functions, only 0.4% of them have differences from the on-prem ones.

Power Scripts Server/DC Functions that are not available in the Cloud (yet)

Some on-prem Jira functions aren't available in the cloud because they're specific to the on-prem version. For instance, admin functions for complete reindexing of Jira aren't necessary in the cloud.

Other functions/functions are not available because of two reasons:

1. there are API limitations from Atlassian’s side

2. we haven’t had the time to build them (yet!)

We’re constantly working on adding new functions to make Power Scripts even more powerful. In 2023, we’ve added 200+ new functions, and there will soon be more cloud functions than on-prem functions.

Will changes still be required?

Unfortunately, some changes will still be required as there are architectural differences between the on-prem version and the cloud version.

Differences that could impact your scripts

A minor difference is one that does come from the differences between a Data Center instance and a Cloud instance but could simply come from different instances running on the same platform. For example differences on a development instance and a product instance, while both might be running on Data Center there could be an impact to the scripts because they are separate instances. These are usually differences in configurations or settings.

Concrete names vs. aliases: If your script uses concrete configuration names instead of aliases, your script has to be updated. This applies to:

• Custom field ID’s

• Project names or keys

• Status/priority names

• Issue type names (or any other object that has a name)

Permission settings - In Power Scripts, each script runs as a user, inheriting that user's permissions. If permissions differ between Jira versions or hosting types, this may impact your script.

Differences that will impact your scripts

Issues arise when on-premises and cloud functionality in Jira is different, and scripts therefore become incompatible.

Conditions and Validators - When Jira Cloud was launched, custom conditions and validators didn’t exist. This is because they completely break the design of the cloud architecture. Performing an action in the cloud sets off a chain reaction of micro-services and events all at once, like knocking over multiple rows of dominos. Conditions and validators require a pause in those events while they determine if the domino should fall over or if it is allowed to fall over. It really doesn't work like that, so instead of being able to use scripted conditions and validators, Atlassian released the expressions language, which is the only available way to create custom conditions and validators.

This means that SIL scripts written for Data Center will either need to be rewritten using the expressions language, reimagined in ways that support the Cloud product, or removed completely.

JQL functions - Jira Cloud does have something that looks like the same JQL functions that were available in on-prem versions, however, they are not real functions. Real JQL functions are executed during the search and run to determine if an issue should be included in the results as part of the query. In the cloud, these results are pre-calculated, and the JQL “functions” just query the result. That is why they are called JQL aliases in the cloud, they are acting like the function would have.

This means that scripts using classic JQL functions found on Data Center will need to have the JQL function rewritten to accommodate the differences in Cloud. Scripts that could be executed as part of a custom JQL search will need to be rewritten as custom JQL keyword (alias) scripts.

Live Fields - Atlassian recently introduced the ability to create a functionality such as Live Fields. As they have only released a few APIs for a select number of custom fields, Live Fields in Cloud (coming 2024) will not be as powerful as on DC.