Often, during the development of an integration or a special customization, people get stuck because of the lack of context. Questions appear: which user clicked the button for the next status? Did the manager approve this item? What was the result of the calculation in the previous step? The traditional way of dealing with such questions was to create additional custom fields to keep that data, usually hidden from users (so excluded from the screens schemes), effectively adding bloat to Jira and ultimately worsening indexing - and general - performance. To help you answer these kinds of questions, Simple Issue Language™ (or SIL™) acquired, starting with version 4.1.7 of the SIL Engine™, a new feature, called persistent variables.
So, what's a persistent variable? In short, in an issue context, a persistent variable is a value inherently linked to the issue. Think of it as an extension of the issue fields, or - making another analogy - an additional custom field, but internal to SIL™. Outside the issue context, the persistent variable becomes a global variable, accessible from all scripts. It is better to see some usage, so you can get a better grasp on what it means and how it can simplify your SIL™ usage throughout your Jira integration.
Usage in an issue context
Persistent variables are introduced via the persistent keyword. In order to save space, we do not allow persistent and constant modifiers to be used on the same variable, so you can't have both. A persistent variable is always modifiable.
...
Note that we didn't put any initializer. If the variable is already initialized, the initializer is simply not executed at all, no matter the construct. While such behavior belongs to the logic of the persistent variable, we recommend that you use the same initializer every time so that you won't start with different values.
Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In conclusion:
- The persistent variable is linked to the current issue from the context.
- Persistent variables are only initialized once. Initialization of a persistent variable will be ignored if that variable was already initialized from a previous execution within a particular context.
- A persistent variable is a variable whose value survives the script, making it available in many other scripts under the same name.
Usage outside the issue context
The usage outside the issue context is very similar. However, due to the nature of the persistent keyword, the variable, in this case, becomes a global variable. Take for instance the following script, run from the SIL™ Runner gadget:
...
Info |
---|
Persistent variables are effectively global if used outside of the issue context. |
Helper routines
There are two helper routines available to ease your work with persistent variables. These routines allow you to set or retrieve the value of a persistent variable from a script that is not in the context of the issue or just to retrieve a global variable:
...
Code Block | ||||
---|---|---|---|---|
| ||||
string globalCounterVar = getPersistentVar("counter"); number test_one_counter = getPersistentVar("TEST-1", "counter"); //notice the implicit cast! values are treated like strings, though! |
Notes
- Although useful, persistent variables come with a small performance penalty. Don't overuse them!
- There's no way to delete a persistent var (other than direct SQL) at the moment. Think hard if you really need them.
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
//This validator script prevents the user from starting work on the issue until it has been approved persistent boolean approved; string errMsg = "You can not perform this action because this ticket has not been approved by a manager"; if(approved != true) { return false, "", errMsg; } |
Stored Passwords
It is not a good practice to have passwords stored in your script. One way to achieve this is to store the password in a persistent variable. To create the password as global variable run the following script once through the SIL Runner Gadget or the SIL Scheduler:
...