Skip to end of banner
Go to start of banner

Cloud Support

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »



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


Main Differences between Cloud and Server


There are notable differences between the cloud solution and the server addon.


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


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 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 postfunctions, listeners, schedulers, ....

Network is Important


Network latency becomes paramount on cloud, for obvious reasons.

Routines and Their Availability


Many of the routines found in Jira Server do access internal APIs. On cloud, we are limited to the REST Api Jira provides.

GDPR, Jira and the add-on


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,




  • No labels