Assess
Before beginning migration we suggest you fully evaluate the differences between ScriptRunner for Jira Server and ScriptRunner for Jira Cloud. It's important you assess your requirements, analyze your current ScriptRunner set-up, and think about timing before creating a migration plan.
Core Platform Differences
Automatic migration between Server/Data Center and Cloud is not possible due to the differences in the programming model and the API, meaning scripts written in Server will not work in Cloud. The process of migration involves analyzing the scripts required, and translating that into a format that will work on the target platform.
Jira Cloud uses the Atlassian Connect framework to allow add-ons like ScriptRunner to provide additional functionality, whereas Jira Server/Data Center use the Atlassian Plugins framework, known as Plugins v2, or P2. There are fundamental differences between Connect and P2 that directly impacts ScriptRunner functionality and script writing, the main ones are outlined in the table below:
P2 (Server/DC) | Connect (Cloud) | |
---|---|---|
API | Java API - it is possible to call almost any of the Host application code directly. Plugins are running in the same JVM as the host application. | REST APIs are available to interact with the host application. Connect has access to a limited set of REST APIs as defined by the Product API Scopes, this means that Connect add-ons can only do things officially supported by the APIs, but it also means that APIs are less likely to change and add-ons are less likely to break as a result. |
UI | Any part of the UI can be customized. Javascript runs as on the page in the same context and frame as the host application. Host application code can be manipulated and broken by add-ons and add-on code can easily be broken by host code (or its dependent libraries) updates. | Specific areas can be customized. Each add-on runs in its own iframe and Javascript Sandbox. Interaction with the host page is via a Javascript API. |
Programming Model | In the same JVM as the host application. Events can be vetoed and code runs synchronously. A bug in add-on code can seriously affect application stability or performance. | Asynchronous. Runs as a completely separate service. No code runs in the same JVM as the host. Events are processed as webhooks that fired from the host and processed asynchronously by the add-on - no waiting for events to be processed. A failing add-on does not impact the performance of an Atlassian application (although functionality may be missing). The asynchronous nature of Connect has implications with regards to host interaction, for example, in Jira it is not possible to implement event listeners that prevent event processing. Similarly when writing ScriptRunner scripts for server hosts, it is important to consider the impact that scripts will have, particularly when interacting with external systems that might be slow. |
Authentication and Authorization | Code can run as any user in the system including as no user (which is not the same as Anonymous). Authentication and authorization can be bypassed. | Add-ons make requests as the add-on user or the user that initiated the interaction. It is not possible to bypass authorization or authentication |
In summary, there are significant differences between the Connect and P2 frameworks and it is necessary to re-think how ScriptRunner scripts execute and interact with the host application when moving from Server/Data Center to Cloud, or Cloud to Server/Data Center.
As with most programming situations there are trade offs when writing scripts for both Cloud and Server/Data Center and the limitations of Cloud are at the expense of stability and performance of the Atlassian application.
Complexity of ScriptRunner Data
Before migrating ScriptRunner it's important to analyze your current set-up. Analyse the purpose/functionality of your existing scripts. We suggest you clean up your instance as much as possible before migrating to simplify this process, our Microscope app can assist you by running project, workflow function, and user audits.
Navigate through each ScriptRunner feature tab, for example listeners, to see a list of all listeners configured on your instance.
Feature Parity
If you are migrating manually, check for feature parity in Cloud and analyse the API.
If you are using the Atlassian Cloud Migration Assistant this is done for you.
ScriptRunner for Jira Cloud does not have the same feature set as the Server/Data Center version. We have noted below the parity of each ScriptRunner for Server/Data Center feature, along with any script/function alternatives where there is currently no value parity.
ScriptRunner for Server/Data Center features, which are not supported in ScriptRunner for Jira Cloud, are also listed in the parity tables for full transparency to allow an informed decision when migrating from Server/Data Center to Cloud.
Jira REST API and UI Modifications API
The varying parities between Cloud and Server/Data Center exist due to the limitations of the Jira REST API and UI Modifications API, which ScriptRunner relies on to allow certain functionality. Unfortunately, it is likely that some features cannot be part of the Cloud feature set due to restrictions in the Cloud platform. There are also some general limitations within ScriptRunner Cloud, such as script execution timeouts and script storage which we recommend reviewing.
Key | Definition |
---|---|
Full value parity. | |
◐ | Partial value parity. |
ALT | No value parity, but custom script alternatives are available. |
No value parity or alternatives are available. |
Behaviours
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Behaviours | ◐ | Atlassian created an API called UI Modifications on the Forge platform, which made it possible for ScriptRunner to build Behaviours. As more capabilities become available in the UI Modifications API, more functionality can be built in ScriptRunner's Behaviours feature. Behaviours is a key focus within ScriptRunner's product development roadmap. We are actively enhancing this feature by integrating new capabilities as Atlassian release them. Notable differences for Behaviours on Cloud:
Although Jira Service Management support is currently not available from Atlassian, we will implement this functionality into Behaviours as soon as it is released. See our Behaviours Limitations section for more details. Notable parity for Behaviours on Cloud:
|
Built-In Scripts
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Built-In: Bulk Copy SLA Configuration | | |
Built-In: Bulk Fix Resolution | ◐ | Jira Cloud does not allow clearing resolutions (selecting None option). |
Built-In: Bulk Import Custom Fields | ALT | The same function can be achieved by writing your own script in the Script Console but with all the caveats of time limitations, API availability, etc. |
Built-In: Change Dashboard, Filter or Board Ownership | ALT | Similar functionality can be achieved by writing a script in the Script Console to call the Change Filter Owner and the Bulk edit dashboards APIs to update and filter dashboard owners. We have created a sample script for this here. |
Built-In: Clean Workflows | | |
Built-In: Clear Groovy Class Loader | ||
Built-In: Configuration Exporter | A third-party tool such as salto.io can provide this. | |
Built-In: Copy Custom Field Values | ◐ | Jira Cloud currently supports:
|
Built-In: Copy Project | ALT | You can achieve the same functionality in Jira Cloud by using the Script Console and a script. |
Built-In: Generate Events | ||
Built-In: Guardrails - Maximum number of comments per issue.
| ALT | You can use the numberOfComments JQL Keyword to search for issues that exceed a maximum number of comments using a JQL query similar to the one below.
You can then manually review these issues and delete the comments if needed. To automate this, you could run this query in the Script Console calling the Archive Issues by JQL API with this JQL to archive all issues returned that exceed this threshold. |
Built-In: Guardrails - Maximum number of unrchived projects | ALT | Similar functionality can be achieved by writing a script in the Script Console to call the Get Projects Paginated API and filter out results where the You can then call the Archive project API for every project returned by this API. We have an example script to do this here, which can be run on the script console. |
Built-In: Guardrails - Maximum Number of Issue Links Per Issue
| ALT | You can use the numberOfLinks JQL Keyword to search for issues that exceed a maximum number of links using a JQL query similar to the one below.
You can then manually review these issues and delete the links if needed. If you wanted to automate this, you could run this query in the Script Console calling the Archive Issues by JQL API with this JQL to archive all issues returned that exceed this threshold. |
Built-In: Guardrails - Maximum Attachment Size
| ||
Built-In: Guardrails - Maximum Change History Records Per Issue | ||
Built-In: List Scheduled Jobs | ||
Built-In: Re-index Issues | ||
Built-In: Script Registry | ||
Built-In: Service Desk Template Comments | ||
Built-In: Split Custom Field Contexts | ALT | Similar functionality can be achieved by writing a script in the Script Console as shown in this example script. |
Built-In: Switch to a Different User | ||
Built-In: Test Runner | ||
Built-In: View Server Log Files |
Code Insights
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Code Insights |
HAPI
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Application links | ||
Assets | ||
Attachments | ◐ | Cloud includes:
|
Comments | Cloud includes:
See the Cloud Work with Comments page for more details. | |
Entity properties | Cloud includes:
For each of the above you can:
See the Cloud Work with Entity Properties page for more details. | |
Fields | Cloud includes:
See the Cloud Update Fields page for more details. | |
Filters | ||
Groups | ◐ | Cloud includes:
See the Cloud Work with Groups page for more details. |
Issues | Cloud includes:
See the Cloud Work with Issues page for more details. | |
Permission schemes | ||
Projects | Cloud includes:
See the Cloud Work with Projects page for more details. | |
Send emails | ||
Users | ◐ | Cloud includes:
See the Cloud Work with Users page for more details. |
Watchers |
Integrations
If you need to call external systems to import data into Jira, consider using ScriptRunner Connect, our powerful integration platform that offers this capability and much more.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Automation for Jira: Asset Object Created Trigger | Automation for Jira provides built-in Asset and Jira actions out of the box in Jira Cloud that can be used directly Note that Automation for Jira triggers and actions are currently unsupported on Cloud. | |
Automation for Jira: Asset Object Updated Trigger | ||
Automation for Jira: Create Asset Action | ||
Automation for Jira: Execute a ScriptRunner Script Action | ||
Automation for Jira: Lookup Asset (Insight) Object Action | ||
Automation for Jira: Lookup Asset (Insight) Objects from AQL (IQL) Action | ||
Automation for Jira: Update Asset Action | ||
Vendors API |
Jobs
This feature is known as Scheduled Jobs in Jira Cloud.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Jobs: Custom Scheduled Job | ◐ | Jira Cloud supports:
|
Jobs: Escalation Service | ◐ | Jira Cloud supports:
|
Jobs: Issue Archiving Job | ALT | This can be achieved by writing a custom escalation service that calls the Archive issue API to archive any issues returned by the JQL query specified on the schedule specified. |
JQL Functions
Both versions of ScriptRunner use JQL Functions. However, this feature has been implemented as Enhanced Search within ScriptRunner for Jira Cloud.
JQL Query Comparison
See our Enhanced Search documentation for JQL Query Comparisons between ScriptRunner for Jira Server/DC and Cloud.
Customized Epic Link field
If you've renamed or customized the Epic Link default field in your Jira instance, you may notice issues with epic-related queries, such as:
Failures with getting automatic syncing and the most up-to-date results.
Epic-related JQL functions (e.g.,
epicsOf, linkedIssuesOf
) not returning expected results.
Atlassian has deprecated the Epic Link field and now recommends using the Parent property to link to epics. Since the Epic Link field was customizable, any epic fields that you have renamed or customized are no longer supported in JQL queries.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
JQL Functions: addedAfterSprintStart | This JQL function will identify issues that were added to an open sprint after the feature was released (21st December 2020). Historical searches for issues added to open sprints prior to that date are not supported. | |
JQL Functions: aggregateExpression | Manually calculate using spreadsheets. | |
JQL Functions: commented | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve you could use some ScriptRunner JQL Keywords to achieve the same: |
JQL Functions: completeInSprint | ALT | There is not a like-for-like match here, but the inSprint JQL function can be used to search for issues in the sprint which have a completed status to get a similar query. |
JQL Functions: componentMatch | ◐ | |
JQL Functions: dateCompare | ||
JQL Functions: earliestUnreleasedVersionByReleaseDate | ||
JQL Functions: epicsOf | ◐ | This JQL function is available for Jira company-managed projects but not for team-managed projects. |
JQL Functions: expression | ||
JQL Functions: fileAttached | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve, you could use some ScriptRunner JQL Keywords to achieve the same: |
JQL Functions: hasAttachments | ALT | There is not a like-for-like function in Cloud, but depending on what you want to achieve, you could use the ScriptRunner JQL Keywords: |
JQL Functions: hasComments | ALT | The ScriptRunner JQL Keyword: |
JQL Functions: hasLinks | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve, you can use native Jira keywords |
JQL Functions: hasLinkType | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve, you can use the native Jira keyword |
JQL Functions: hasRemoteLinks | ||
JQL Functions: hasSubtasks | You could use the ScriptRunner JQL Keywords: | |
JQL Functions: inactiveUsers | ||
JQL Functions: incompleteInSprint | ALT | There is not a like-for-like match here, but the inSprint JQL function can be used to search for issues in the sprint which have a not completed status to get a similar query. |
JQL Functions: issueFieldExactMatch | This feature is called | |
JQL Functions: issueFieldMatch | ||
JQL Functions: issuesInEpics | This JQL function is available for Jira company-managed projects but not for team-managed projects. | |
JQL Functions: jiraUserPropertyEquals | ||
JQL Functions: lastComment | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve you could use the |
JQL Functions: lastUpdated | ALT | There is not a like-for-like function in Jira Cloud, but depending on what you want to achieve you could use the |
JQL Functions: linkedIssuesOf | This function can be used in Jira Server/Data Center to search for issues linked with the parent-child hierarchy provided by Advanced Roadmaps/Portfolio but not in the Jira Cloud Enhanced Search. | |
JQL Functions: linkedIssuesOfAll | ||
JQL Functions: linkedIssuesOfAllRecursive | ||
JQL Functions: linkedIssuesOfAllRecursiveLimited | ||
JQL Functions: linkedIssuesOfRecursive | ||
JQL Functions: linkedIssuesOfRecursiveLimited | ||
JQL Functions: linkedIssuesOfRemote | ||
JQL Functions: memberofRole | ||
JQL Functions: myProjects | ||
JQL Functions: nextSprint | ||
JQL Functions: overdue | ||
JQL Functions: parentsOf | ||
JQL Functions: portfolioChildrenof() | ◐ | JQL function childrenOf can be used to find all descendant issues of a given subquery, including children, grandchildren, and beyond. |
JQL Functions: portfolioParentOf() | ◐ | JQL function parentsOf can be used to find all ancestor issues of a given subquery, including parents, grandparents, and beyond. |
JQL Functions: previousSprint | ||
JQL Functions: projectMatch | In Jira Cloud this function uses the | |
JQL Functions: projectsOfType | ALT | There is no like-for-like match here, but you can use the native Jira keyword of projectType to return all issues from projects of a certain type such as Software. |
JQL Functions: recentProjects | ALT | There is no like-for-like match here, but you can use the native Jira keyword of lastViewed to return issues you last viewd in the past x days to see what projects you interacted with in that timeframe. |
JQL Functions: releaseDate | ||
JQL Functions: removedAfterSprintStart | ||
JQL Functions: startDate | ||
JQL Functions: subtasksOf | ||
JQL Functions: versionMatch | ||
JQL Functions: workLogged |
Listeners
This feature is known as Script Listeners in Jira Cloud.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Listeners: Adds the current user as a watcher | ALT | The same function can be achieved using a Custom Listener and a script. |
Listeners: Clone an issue and links | ALT | The same function can be achieved by writing your own script in the Custom Listener but with all the caveats of time limitations, API availability, etc. Check out our page on Scripting in ScriptRunner for Jira Cloud for tips. We have an example script to show how to clone an issue and link it here. |
Listeners: Create a sub-task | ALT | The same function can be achieved using a Custom Listener and this script for creating a subtask(s). |
Listeners: Custom Listener | ◐ | There is a limit of 240 seconds for script executions. After running for 240 seconds, the logs will be collected, and the code will be terminated. Currently, a custom event may not be created and used to trigger listener actions. Events supported in Cloud: The list below shows the list of events that Jira Cloud supports to trigger listener actions from: |
Listeners: Execution failure notifier | ALT | In Jira cloud, the Notifications group setting allows you to specify a group of users who will get an email each time a script fails, but this can't be configured to send to other messaging services such as Slack because the notify API doesn’t allow you to email external emails. |
Listeners: Fast-track transition an issue | ALT | The same function can be achieved using a Custom Listener and a script to transition an issue. |
Listeners: Fires an event when a condition is true | ALT | In Jira Server/Data Center, this listener is used to send an email when a condition occurs. In Jira Cloud, you can add the condition to be matched to the script conditions box, which uses the Jira Expression Framework. When the condition is true, you can call the Send notification for issue API to send a notification to specific users, similar to what is shown in the example script here. |
Listeners: Post a message to slack | ALT | The same function can be achieved using a Custom Listener and a script to Post to Slack. |
Listeners: Send a custom email (non-issue events) | ALT | The same function can be achieved using a Custom Listener and a script to send a notification. The notify API doesn’t allow you to email external emails and only allows you to notify users, groups, or user fields (such as assignee or reporter) on an issue. |
Listeners: Send a custom email | ALT | The same function can be achieved using a Custom Listener and a script to send a notification. The notify API doesn’t allow you to email external emails and only allows you to notify Jira users, groups, or user fields (such as assignee or reporter) on an issue. The API does not allow users to send notifications to themselves. |
Listeners: Version Synchronizer | ALT | The same function can be achieved by writing your own script in the Custom Listener but with all the caveats of time limitations, API availability, etc. Check out our page on Scripting in ScriptRunner for Jira Cloud for tips. |
Mail Handler
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Mail Handler |
Resources
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Resources: Database Connection | ALT | You can connect to databases in scripts and link to the examples we have in the Script Console examples. |
Resources: LDAP Connection | ALT | If the LDAP service exposes a REST API, you could connect to this in Scripts by making a REST API call. |
Resources: Local Database Connection | ||
Resources: Slack Connection | ALT | You can connect to Slack in scripts via the REST API and link to the examples we have in the Script Console examples. |
REST End-Points
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
REST End-Points: Custom End-Point | Unlike Server/Data Center, Jira Cloud does not offer custom end-points. Instead it uses the Atlassian REST API. However, with ScriptRunner, you can still connect and interact with other systems by calling their external APIs. |
If you need to call external systems to import data into Jira, consider using ScriptRunner Connect, our powerful integration platform that offers this capability and much more.
Script Console
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Script Console | There is a limit of 240 seconds for Cloud script executions. After running for 240 seconds, the logs will be collected, and the code will be terminated. |
Script Editor
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Script Editor |
UI Fragments
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
UI Fragments | ◐ | ScriptRunner for Jira Cloud supports Web Panels only. Script source must be specified (and accessible to Jira), inline script is not available. |
Script Fields
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Script Fields: Custom Script Fields | ◐ | Due to current limitations, the value of Scripted Fields will currently only refresh on issue view. |
Script Fields: Custom Picker | ||
Script Fields: Database Picker | You can connect to databases in scripts and link to the examples we have in the Script Console examples. | |
Script Fields: Date of the first transition | ALT | The same function can be achieved using a Custom Scripted Field and a script using a Text Field type. |
Script Fields: Issue(s) Picker | ||
Script Fields: LDAP Picker Field | If the LDAP service exposes a REST API, you could connect to this in Scripts by making a REST API call. | |
Script Fields: No. of times in a status | ALT | The same function can be achieved by writing your own script in the Custom Scripted Field but with all the caveats of time limitations, API availability, etc. Check out our page on Scripting in ScriptRunner for Jira Cloud for tips. |
Script Fields: Remote issue(s) picker | ALT | You can link to issues in a remote Jira instance using the Create remote issue link API inside a script. We have an example of using this API here. |
Script Fields: Show parent issue in a hierarchy | ALT | The same function can be achieved by writing your own script in the Custom Scripted Field but with all the caveats of time limitations, API availability, etc. Check out our page on Scripting in ScriptRunner for Jira Cloud for tips. |
Script Fields: Time of Last status Change | ALT | The same function can be achieved using a Custom Scripted Field and a script using a Text Field Type. |
Settings
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Script Edit Permissions | | |
Hapi Code Helper | ||
In-App Communications | ◐ | There is no opt-in for this, but we use in-app banners and popups to communicate information relating to Scriptrunner for Jira Cloud. |
Switch User Function | ||
Anonymous Analytics | ||
User Editor Settings |
Workflow Conditions
ScriptRunner for Jira Cloud provides workflow conditions using the Jira Expression Framework. It is not possible to use the REST API.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Workflow > Condition: All sub-tasks must be resolved | ALT | The same function can be achieved using a custom script condition and a script to check all sub-tasks are resolved. |
Workflow > Condition: Allows the transition if this query matches a JQL query |
| |
Workflow > Condition: Checks the issue has been in a status previously | ALT | The same function can be achieved using a custom script condition and a script that Checks the Issue Has Been in a Status Previously. |
Workflow > Condition: Custom script condition | ALT | Cloud conditions use Jira Expression language where the result must be true or false. Cloud function name: Incompatible fields that should be discarded:
|
Workflow > Condition: Field(s) required condition | ALT | The same function can be achieved using a custom script condition and a Field(s) Required script. |
Workflow > Condition: Group(s) condition | ALT | The same function can be achieved using a custom script condition and a script to check the user is within a specified user group. |
Workflow > Condition: JQL query matches condition | | |
Workflow > Condition: Linked issues condition | ALT | The same function can be achieved using a custom script condition and a Linked Issues script. |
Workflow > Condition: Project role(s) condition | ALT | The same function can be achieved using a custom script condition and a script to check the user is within a specified project role. |
Workflow > Condition: Regular expression condition | ALT | The same function can be achieved using a custom script condition and the Regular Expressions script. |
Workflow > Condition: Simple scripted condition | ◐ | Cloud conditions use Jira Expression language where the result must be true or false, it does not use Groovy. |
Workflow > Condition: User in field(s) condition | ALT | The same function can be achieved using a custom script condition and the User in Field(s) script. |
Workflow > Condition: User(s) and User Group(s) condition | ALT | The same function can be achieved using a custom script condition and the User(s) and User Group(s) script. |
Workflow Post Functions
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Workflow > Post Function: Add a comment to this issue | ALT | The same function can be achieved using a custom post function and a script. |
Workflow > Post Function: Add/remove from sprint | Cloud function name: Incompatible fields that should be discarded:
| |
Workflow > Post Function: Adds a comment to linked issues when this issue is transitioned | ALT | The same function can be achieved using a custom post function and a script. |
Workflow > Post Function: Adds the current user as a watcher | ALT | The same function can be achieved using a custom post function and a script. |
Workflow > Post Function: Archive this issue | ALT | This can be achieved by writing a script to call the Archive issue API to achieve this. Note: to use this API, you need to be on the Premium or Enterprise tiers of Jira Cloud. |
Workflow > Post Function: Assign to first member of role | ALT | The same function can be achieved using a custom post function. Cloud function name: Incompatible fields that should be discarded:
|
Workflow > Post Function: Assign to last role member | ALT | The same function can be achieved using a custom post function. |
Workflow > Post Function: Clear field(s) post function | ALT | The same function can be achieved using a custom post function and a script. |
Workflow > Post Function: Clones an issue, and links | Cloud function name: Incompatible fields that should be discarded:
| |
Workflow > Post Function: Copy field values | ALT | The same function can be achieved by writing your own script in the custom post function but with all the caveats of time limitations, API availability, etc. Check out our page on Scripting in ScriptRunner for Jira Cloud for tips. We have an example script to show how to clone an issue and link it here. |
Workflow > Post Function: Create a sub-task | Cloud function name: Incompatible fields that should be discarded:
| |
Workflow > Post Function: Custom script post-function | Cloud function name: | |
Workflow > Post Function: Fast-track transition an issue | Cloud function name: Incompatible fields that should be discarded:
| |
Workflow > Post Function: Fires an event when condition is true | ALT | This post function is used to send an email when a condition occurs in Jira Server/Data Center. In Jira Cloud you can add the condition to be matched to the script conditions box on a custom post function. When the condition is true, you can call the Send notification for issue API to send a notification to specific users, similar to what is shown in the example script here. |
Workflow > Post Function: Post a message to Slack | ALT | The same function can be achieved using a custom script post-function with a script to post to Slack. |
Workflow > Post Function: Send a custom email | The equivalent in Cloud is “Send Notification”. | |
Workflow > Post Function: Set issue security level depending on the provided condition | ALT | This can be achieved by writing a script that, if the condition matches, calls the Edit Issue API and updates the issue to set the security field on an issue. We have an example of setting issue security here. |
Workflow > Post Function: Transition parent when all subtasks are resolved | ◐ | Cloud function name: The same function can also be achieved using the fast-track transition issue built-in post function and adding a condition script to verify all subtasks are resolved. |
Workflow Validators
ScriptRunner for Jira Cloud provides workflow validators using the Jira Expression Framework. It is not possible to use the REST API.
Server/DC Feature | Cloud Parity | Parity Notes/Alternatives |
---|---|---|
Workflow > Validator: Custom script validator | ALT | Cloud conditions use Jira Expression language where the result must be true or false. Cloud function name: Incompatible fields that should be discarded:
|
Workflow > Validator: Field(s) changed validator | ALT | The same function can be achieved using a custom script validator and the Field(s) Changed script. |
Workflow > Validator: Field(s) required validator | ALT | The same function can be achieved using a custom script validator and the Field(s) Required script. |
Workflow > Validator: Regular expression validator | ALT | The same function can be achieved using a custom script validator and a script. |
Workflow > Validator: Require a comment on transition | ALT | This script can be used to enforce that a comment has been given on transition. |
Workflow > Validator: Simple scripted validator | ◐ | Cloud conditions use the Jira Expression language where the result must be true or false, it does not use Groovy. |
Workflow > Validator: User in field(s) validator | ALT | The same function can be achieved using a custom script validator and a script. |
If there is no feature parity, we suggest you analyse the value parity:
- What is the script doing?
- Is it required in Cloud?
- Is there a similar Cloud feature that could cover the requirement?
Cloud Migration Assistant
The following features are migrated from Jira Server to Jira Cloud when using the Jira Cloud Migration Assistant:
- Custom Script Field
- Custom Script Listener
- Custom Jobs
- Escalation Services
- JQL Functions
- epicsOf
- nextSprint
- linkedIssuesOfRecursive
- subtasksOf
- previousSprint
- parentsOf
- dateCompare
- expression
- componentMatch
- linkedIssuesOf
- issueFieldMatch
- issuesInEpics
- linkedIssuesOfRecursiveLimited
- issueFieldExactMatch
- versionMatch
- hasLinkType
- hasComments
- hasSubtasks
- hasLinks
- Workflow Functions
- Custom Validator
- Custom Condition
- Custom Post Function
- Post Function Add/Remove from Sprint
- Post Function Assign to Last Role Member
- Post Function Clones an Issue and Links
- Post Function Create a Sub-task
- Post Function Fast-track Transition an Issue
- Post Function Transition Parent When all Sub-tasks are Resolved
- Post Function Send a Custom Email
Once migrated, these features are deactivated so you can make them Cloud compatible before reactivating.
- Known Issues (Rename from Pitfalls) - things to be aware of such as valid queries on JQL functions