Contents
Table of Contents |
---|
Excerpt |
---|
Aliases represents a powerful tool to refer custom fields indirectly making your scripts function obvious. |
The Case For Aliases
...
Addressing fields by its Jira internal name is not useful. Nobody likes to write 'customfield_12067' instead of a meaningful variable name. Thus we allowed to address the fields by name though with the disadvantage that certain errors may appear: field name resolution does not take into account that there may be more than one custom field with that name.
...
Code Block |
---|
if(isNotNull(customfield_10001) // or #{The Reported User)} if accessed by name { assignee=customfield_10001; // assign the report to him or her } |
This code is meaningless without comments as the whole script purpose evades from the programmer's eye. A better option is following:
Code Block |
---|
if(isNotNull(#{Reported User}) // or customfield_10001 if accessed by number { assignee=#{Reported User}; // assign the report to him or her } |
Such coding style has the disadvantage that there may be more than one custom field with Reported User name. In such case SIL SIL™ takes into account the first custom field resolved by name. Therefore, SIL has created its own custom field naming system, one that is independent of the IDs attributed by Jira to custom fields and one that can provide the much better distinction of the custom fields names. The feature is called SIL SIL™ aliases, and allows you to alias any custom field with a friendly name. Let's see how this simple example looks with aliases.
...
Creating aliases is a simple task of editing a properties file named 'sil.aliases', that is placed in Kepler cPrime Home directory. This file must contain pairs in the form alias=customfield_id. For our example above, we should edit it and put an entry like:
Code Block | ||
---|---|---|
| ||
# custom fields aliases reportedUser=customfield_10001 |
...
The script may be re-written in another way, instead of the custom field ID or name the alias is used:
...
Now the code looks clean and the script function creator is clear even without comments.
Summary
Using SIL SIL™ aliases instead of custom fields IDs and names is supreme. There are important results when maintaining a complex Jira install:
...
- You create on the production system a custom field with the same name. But Jira assigns its own ID, that may be different from the ID on the test system.
- You move over the SIL SIL™ scripts.
- You import the workflow, with the paths changed to the above SIl SIL™ scripts if necessary.
Now, if you referred your custom field by its ID, you need to go through every script and do a search and replace with the new ID. If you referred it by name, maybe your colleague just added a custom field, used in some other project, that has the same name.
However, if you used the alias, you just place your alias in that file, and everybody is happy.
Note |
---|
It is important to keep aliases names unique. If more than one alias with the same name exists, the last one is taken into account, the rest are discarded. |
Another Example
If you're still not convinced, let's take a look at another example. Look into this post function:
...
Code Block | ||
---|---|---|
| ||
initialDate=customfield_10000 finalDate=customfield_10001 contact=customfield_10002 |
Then we use them in our SIL SIL™ program.
Code Block | ||
---|---|---|
| ||
if(initialDate < currentDate() && finalDate > currentDate()) { assignee = contact; } |
Something starts to make sense, don't you think?