Page Comparison

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.

...

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

...

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

...

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

...

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

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.