Contents

The Case For Aliases

The case for the aliases

Addressing fields by its their Jira internal name is not really niceuseful. Nobody likes to write 'customfield_12067' instead of a meaningful variable name. This is why we allow addressing Thus, we allowed to address the fields by name, 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 are maybe can 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 comments, this code meaning is elusive, the whole purpose of the script evades from the sight of the programmer. A better variant isThis code is meaningless without comments because the whole script purpose evades from the programmer's eye. A better option 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 "Reported User", in which case SIL with the Reported User name. In such 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 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 that can provide the a much needed uniqueness 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. 

Aliases

...

Creating aliases is a simple task of editing a properties file named the 'sil.aliases', which need to be found 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:

Code Block
title sil.aliases
# custom fields aliases reportedUser=customfield_10001

 

...

Note
The sil.aliases file is located in the kepler directory inside of <JIRA_HOME>. This directory can be accessed from the SIL Manager by changing the View to be cPrime Home Image Added

You can rewrite the script in another way and use alias instead of the custom field id 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.

 

Consequences

...

Summary

Using SIL SIL™ aliases instead of custom fields ids 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 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 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 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 JIRA 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 will be is happy. 

...

Another

...

example

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 SIL™ program ...

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

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