| Warning |
|---|
Looking for the documentation on the newest versions of Power Scripts for Jira 8 for Server/Data Center? Click here ! |
| Table of Content Zone | |
|---|---|
|
Introducing the next generation of automation for the next generation of Jira, Power Scripts for Jira Cloud version 1.1.0. Built for reliability and speed, this platform gives you the flexibility of scripting and the power to integrate with all your business systems such as email systems, LDAP servers, and external databases, all while preserving security.
Changes in the New Version
For those impatient to know what's new, here's a list of changes in the new version (published April 2019):
...
- GDPR compliance
SIL Engine was published into Cloud more than a year ago as an experimental project. Our aims were, and still are:
- to give power of scripting to the users on Cloud
- to allow as much integration as the user wants. We opened DB acess / LDAP integration / mail integration / etc
::TODO::
- User under which add-on runs
- Stability and performance fixes.
- SIL Manager has a log viewer and output console so you can test scripts and view what's really going on with your Jira instance
GDPR, Jira and the Power Scripts add-on. Also, who runs this?
As a big change in the latest versions, GDPR is fully enforced on Jira Cloud. Power Scripts will requests, depending on the script, the user details. The user key is not a username anymore, but the account id of the user making the requests. This means that assignee == "john" may not work anymore, but instead it will be replaced by a more cryptic account id. We do recommend you to use constants instead of direct usernames so you can script them easily.
Starting with the latest version, all calls which are made on Jira are made with the add-on user, and we are not acting anymore as the real user. This change was necessary to avoid confusion. Now, if you provide the necessary rights to the add-on, you can pretty do anything we have capabilities for.
| Note |
|---|
You must understand that, on Cloud, at the level of the script, the user is just 'simulated'. We are no longer like in the server solution, in the same memory space as Jira. There are no real users at the level of the "engine". runAs() routine just establishes what currentUser() will return.
|
| Code Block |
|---|
//example
assignee = "john"; //doesn't work anymore, safer alternative is:
assignee = usernameToUserKey("john"); //assume john didn't opt for strong privacy
// however, this will always work:
const string JOHN_ACCOUNT_ID = "ah383-1bb6-56"; //replace with real account-id
assignee = JOHN_ACCOUNT_ID; //yay! |
Performance & Stability
Now fully asynchronous for all I/O operations We basically re-written the entire Atlassian Connect framework to perform asynchronous IO, thus enabling faster response times. On the engine side, we lowered the memory consumption and improved performance and stability under load. Statistics are now presented on the SIL Engine status page, while record logs are shown in the engine management page
|
|
|---|
SIL Manager Console & Log Access
We believe it is one of the most important change, since now you can see the errors for yourself and understand what's going on there so you can keep your instance smoothly running. We'll just post some imagery here, since words seem futile:
|
|
|---|
We hope that this will ease the pain of the SIL developers, who were unaware of the problems of their own scripts, and also allow us to do faster fixes on the engine.
Differences between Cloud and Server
There are notable differences between the cloud solution and the server addonadd-on. While the most important ones are listed below, bear in mind that that may be others as well. Jira Cloud is evolving as we speak, and we'll evolve with it.
Asynchronous Processing Model
Cloud is fully asynchronous and all our hooks are fired asynchronously, while on server everything is synchronous unless you say so. This means that, for instance, you have 2 postfunctions post-functions attached to a workflow action, first modifying the issue, you most probably won't receive for the second the modifications in SIL. Both are fired (most probably) with the last known data Jira has, they are received on add-on addon side. There's also no guaranteed order of execution. The second may finish earlier than the first one, and its result may be overwritten by the second.
For this reason, we advise users to keep one single post-function per transition, or, if you decide to use multiple post-functions, these should be disjointed in effects (i.e. should not influence each-other).
Less Integration Points
There are less integration points on Jira Cloud than on server. Specifically, we are talking about the fact that workflows cannot have conditions (because asynchronicity above) or validators (same). The addon add-on itself doesn't run free, but it's embedded in an iframe , - like in a cage of some sort , - for security reasons. Therefore there will never be something like LiveFields implemented for cloud. We are restricted at what Jira offers as integration points, i.e. workflow postfunctionspost-functions, listeners, schedulers, ....panels, etc
Network is Important
Network latency becomes paramount on cloud, for obvious reasons. cPrime is considering soon localization for servers. We, as developers, are fighting every millisecond on our side, as well.
Keep in mind that the solution uses polling of the add-on as a refresh mechanism, since there are no hooks and nothing native to determine if a issue has been changed by a REST call. While this call is short in terms of data transferred, the problem is the high amount of requests that have to be made to the solution. You may notice that refresh is not instant after post-function execution / listener execution. The same problem stated above holds true here, the asynchronous processing model and the latency of the network will play a major part in 'feeling' the performance.
Routines and Their Availability
Many of the routines found in Jira Server do access internal APIs, allowing Power Scripts to do crazy things, or even jump between plugins, getting and updating data everywhere. On cloud, we are limited to the REST Api Jira provides.
...
,
...
GDPR is respected by Jira. Addon will requests, depending on the script, the user details. The username is not a username anymore, but the account id of the user making the requests. This means that assignee == "john" may not work anymore.
Who runs this?
Starting with the latest version, all calls which are made on Jira are made with the addon-user, and we are not acting anymore as the real user. This change was necessary to avoid confusion, since many users complained that they cannot run scripts for regular users. Now, if you provide the necessary rights to the add-on,and as of now, we know many are still missing. We're trying to cover as much ground as possible in the shortest time, but please, do engage with us and tell us what you need, it will bump priorities in our backlog.
The routines that you can use on cloud are label with ps_cloud. Please note that there may be differences in the way the routines are called or on the return type, between versions. You'll find all the information in the documentation page of every routine.