Contents

...

The

...

case for the aliases

Addressing fields by its their Jira internal name is not useful. Nobody likes to write 'customfield_12067' instead of a meaningful variable name. Thus, we allow addressing allowed to address the fields by name though with the disadvantage that this may prove erroneous (. Though you should keep in mind that certain errors might still appear because the field name resolution does not take into account that there may can be more than one custom field with that name).

Look into the following code:

if(isNotNull(customfield_10001) // or #{The Reported User)} if accessed by name
{
  assignee=customfield_10001; // assign the report to him or her
}

Without comments, this This code is meaningless , without comments because the whole script purpose evades from the sight of the programmer's eye. A better option is would be the following one:

if(isNotNull(#{Reported User}) // or customfield_10001 if accessed by number
{
  assignee=#{Reported User}; // assign the report to him or her
}

As we mentioned, this style of coding Such coding style has the disadvantage that there may might be more than one custom field named "with the Reported User" name. in In such case SIL cases SIL™ takes into account the first custom field resolved by name. This may not prove exactly what you want and may lead to confusion, incorrect results and last but not least, frustration. We want to avoid frustration at any cost. Plus, we do not like very much the syntax #{custom field name containing spaces} - even if it was requested by our users -, since we consider it is cluttering the code.Therefore, SIL 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 which that can provide the a 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 the 'sil.aliases', which is placed in Kepler Home directory (usually 'kepler') properties file in the cPrime Home directory. This file must contain pairs in the following form: alias=customfield_id.
For our example above, we should edit it and put an entry like this:

# custom fields aliases
reportedUser=customfield_10001

...

You can rewrite the script in another way and use alias instead of the custom field id ID or name, we use the alias: 

if(isNotNull(reportedUser)) {
  assignee=reportedUser;
}

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 IDs and names is supreme. There are important results when maintaining a complex Jira install:

1. When and if a custom field gets deleted and recreated, its id will changeID changes. Using SIL SIL™ aliases allows you to keep your code unchanged, you just need to point in the sil.aliases file the new custom field id ID for that alias.
2. May simplify the Simpler syntax and may clarify the clearer meaning of the scripts.
3. Aliases provide independence of the Jira instance.

Since 1 and 2 are obvious, let's discuss the 3rd point: the independence of the Jira instance.   Think of two Jira systems, for instance test environment and a production environmentone. You do not want to work directly into production (that would be a very bad thing to do, don't do this at home) so normally you develop your new workflow on the test machine environment and you add a new custom field, because the business needs it. Now, everything is ready and you want to publish changes into production system, so:

• You create on the production system a custom field with the same name (but name on the production system. But Jira assigns its own idID, which that may be different from the id from 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 idID, you need to go through every script and do a search and replace the old ID with the new idone. 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:

...

 initialDate=customfield_10000
 finalDate=customfield_10001
 contact=customfield_10002

Then we use them in our SIL SIL™ program.

 if(initialDate < currentDate() && finalDate > currentDate()) {
 	assignee = contact;
 }

Something starts to make sense, don't you think?