One of the main benefits of SIL is, that scripts are portable across instances and hosting types. 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. However, Atlassian did a pretty good job of making the different API versions as similar as possible, at least from our perspective. However, occasionally there are differences.

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.

Different functions (functions) are available

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 XXXX differences between the on-prem version and the cloud version.

Differences that could impact your scripts

A minor difference is one that does not impact the functionality of the tool in any way but may impact a script. These are usually differences in configurations or settings.

Custom field IDs - Custom field IDs will always be different between Jira versions. If your script uses concrete custom field IDs instead of using aliases, your script has to be updated.

Project names or keys - While end users may not see a difference between old project names/keys and new ones. this could make a huge difference to a script that uses those names/keys to search for issues.

Status/Priority names - Just like project names, they may be explicitly used in a script, causing it to break if they are different.

Issue type names (or any other object that has a name) - Really, anything with a name. If the names change, the scripts could be impacted.

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.

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.

Email - Custom email handlers don’t exist in Jira Cloud. It is, therefore not currently possible to send/receive email in Jira Cloud. We plan on building our own version into the product but it does currently not exist. However, it will require a different email address then the one provided by Atlassian. While you can still send outgoing emails from the cloud it to must be done using a different email account. Atlassian simply does not provide any access to the email service for security reasons.

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.