...
Even though SIL works just fine as a standalone scripting language outside Jira (for example our installers use SIL to copy the apps to your Jira directory), but inside Jira it really makes a difference.
Architecture
The SIL language is actually independent from Jira. It can be used for any purpose, for instance be applied for Confluence. It can be applied for anything. On top of the basic interpreter we've also added a Jira specific interpreter which predefines the standard variables, the key variable for instance which represents the key of the issue.
...
As you can see, Jira SIL interpreter basically extends the capabilities of the standard interpreter. The standard SIL Interpreter provides a registry for all routines and the Issue SIL Interpreter adds the additional routines into this registry including Jira interactions.
Contexts
Just like any other programming language, a standalone SIL program contains variables, functions, and conditional and repetitive clauses. Putting this inside a Jira context enables you to use Jira related routines like createIssue or linkIssue (so the script "has Jira context"). Adding an issue context inside the Jira context (so the script "has an issue context"), enables you to use field values stored on the issue, regardless of whether they are standard fields like summary, description, assignee, or custom fields.
...
| Info | ||
|---|---|---|
| ||
All scripts used by our Jira apps have Jira context, but not necessarily an issue context. This is important because without an issue context you will not be able to use such variables like summary, assignee, or custom fields right away. |
Post processing
Note, that when running inside a Jira context, there is a step called "behind-the-scene post-processing". During the interpretation of the script, the SIL Engine (or Interpreter) creates volatile clones (not persistent) of all issues that were modified and the respective changes. This enables us to control the following aspects of a program:
...