Differences between Workflow Magic Box for Jira Server and Jira Cloud
Although Workflow Magic Box for Jira Cloud adheres to the same principles as Jira Server and Data Center, the execution model is very different because of the difference in the APIs the apps could use to communicate and modify Jira. Additionally, because Atlassian Connect is asynchronous by nature, a script may finish before the user sees the page loading.
Platform Variations
Because of the variations in the programming paradigm and API, currently there is not an automatic migration path between Server/Data Center and Cloud. Analyzing and translating the intended functionality into the destination platform are the suggested steps in the migration process.
Functionality Parity
Most of our DC functionalities have been integrated into Jira Cloud and many of them have been improved.
In addition, the interface has been improved by adding better input fields and more customization options.
| Definition |
|---|---|
Full value parity. | |
| Functionality in progress. |
| No value parity or alternatives are available. |
| Improved functionality. |
Server/DC Functionality Name | Cloud Parity | Notes |
|---|---|---|
Conditions | ||
Project Component Condition |
| |
Groovy Script condition | As conditions are asynchronous functionalities and Atlassian is the one who evaluates them, it is not possible to make a custom script, you can only make custom conditions using Jira Expressions. | |
Issue Type Condition |
| |
JQL Condition | As conditions are asynchronous functionalities and Atlassian is the one who evaluates them, it is not possible to make a custom script, you can only make custom conditions using Jira Expressions. | |
Only Component Lead Condition | Discarded since to validate the condition there is no option in Jira Expressions to recover the component lead, only the ID or Name can be recovered. | |
Only Project Lead Condition |
| |
Only the reporter | Already exists in Jira Cloud. | |
Project Category Condition |
| |
Project Condition |
| |
Status Condition |
| |
User Is In Custom Field | Already exists in Jira Cloud. | |
User is in group(s) | Already exists in Jira Cloud. | |
User is in project role(s) | Already exists in Jira Cloud. | |
Validators | ||
Conditional Required Field Validator |
| Improved, now allows concatenating conditions to define a more complex validator. |
Date validator | Already exists in Jira Cloud. | |
Fields Comparator Validator |
| |
Groovy Script validator | As validators are asynchronous functionalities and Atlassian is the one who evaluates them, it is not possible to make a custom script, you can only make custom validators using Jira Expressions. | |
Has Linked Issues Validator |
| |
Has SubTasks Validator |
| |
Has Worklog Validator |
| Improved, now allows defining the verification of a minimum worklog time. |
JQL Validator | As validators are asynchronous functionalities and Atlassian is the one who evaluates them, it is not possible to make a custom script, you can only make custom validators using Jira Expressions. | |
Linked Issues Status Validator |
| |
Multiple Required Field Validator | Already exists in Jira Cloud. | |
Regular Expression Validator | Already exists in Jira Cloud. | |
Required Field Validator | Already exists in Jira Cloud. | |
SubTasks Status Validator |
| |
User Has Work Logged Validator |
| Improved, now allows defining the verification of a minimum worklog time. |
User is in any group(s) | Already exists in Jira Cloud. | |
User is in any project role(s) | Already exists in Jira Cloud. | |
Value Changed on Transition Validator | Already exists in Jira Cloud. | |
Postfunctions | ||
Add or Remove Watchers |
| |
Clone Issue |
| |
Comment Issue |
| |
Comment parent or child issues |
| |
Copy Value From Field / Custom Field | Already exists in Jira Cloud. | |
Copy field/customfield from/to related issue |
| |
Fire Event | The Jira Cloud API is not able to fire events. | |
Generate UUID |
| |
Groovy Script postfunction |
| |
Http Request |
| |
Send Email |
| |
Set Issue Security Level |
| Improved, in addition to being able to comfortably select the security level filtered according to schemes, the possibility of changing the security level based on a custom field is added. |
Transition Linked Issue |
| |
Update Field / Custom Field Value |
| Improved, it is now possible to set the value of more than one field at the same time, in addition, depending on the type of field, the corresponding format is applied and the "select list" type fields offer you the possibility of choosing the value from the options available. |
New Added Functionalities
Cloud Functionality Name | Type | Notes |
|---|---|---|
Add/Remove labels | Postfunction | This postfunction will add or remove labels in the transitioning issue. |