Contents

The Case For Aliases

...

Addressing fields by its Jira internal name is not really niceuseful. Nobody likes to write 'customfield_12067' instead of a meaningful variable name. This is why Because of that we allow addressing the fields by name, with the disadvantage that this may prove erroneous (field name resolution does not take into account that there are maybe may be more than one custom field with that name).

Consider 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
}

In absence of Without comments, this code meaning is elusivemeaningless, the whole script purpose of the script evades from the sight of the programmer. A better variant option is following:

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 has the disadvantage that there may be more than one custom field named "Reported User", . in which such case 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 has created its own custom field naming system, one that is independent of the IDs attributed by JIRA Jira to custom fields and one which can provide the much needed uniqueness better distinction of the custom fields names. The feature is called SIL aliases, and allows you to alias any custom field with a friendly name. Let's see how this simple example looks with aliases.

Aliases

...

Creating aliases is a simple task of editing a properties file named 'sil.aliases', which need to be found is placed in Kepler Home directory (usually 'kepler'). This file must contain pairs in the form alias=customfield_id. For our example above, we should edit it and put an entry like:

...

The script may be re-written suchin another way, instead of the custom field id or name, we use the alias: 

 

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

   

 

 

Now, the code looks clean, and the intention of the script function creator is clear, even without comments.

 

...

Summary

Using SIL aliases instead of custom fields ids and names is paramountsupreme. There are important consequences results when maintaining a complex JIRA Jira install:

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

If Since 1 & and 2 are obvious, let's discuss a bit about the 3rd point: the independence of the JIRA Jira instance.  Think of two JIRA Jira systems, say for instance test environment and production environment. 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 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 JIRA Jira assigns its own id, which may be different from the id from the test system)
• You move over the SIL scripts
• You import the workflow, with the paths changed to the above 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 will be is happy.

...

If you're still not convinced, let's take a look at another example. Consider Look into this postfunctionpost function:

 if(customfield_10000 < currentDate() && customfield_10001 > currentDate()) {
	assignee = customfield_10002;
 }

...

From the code above, it is quite clear that customfield_10000 and customfield_10001 are dates; customfield_10002 is a user picker. But their meaning is obscureunknown. However, if we define the following aliases:

 initialDate=customfield_10000
 finalDate=customfield_10001
 contact=customfield_10002

 ... then Then we use them in our SIL program...

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

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