Example Script Rules

Summary

With Script Rules there are a huge amount of possible connections that can be created. Below are some examples that can be used to help assist with your configuration.

Match a specific ‘matched’ catchemail mailbox address

This script will gather the Catchemail address that was matched and then check if it is a specific address.

if (jemhUtils.getCatchEmailAddress().getAddress() === "mailbox@blah.com"){ result.setMatch(true); }

Match a specific sender email address

This script will gather the From Address and if matched then it will set this rule as a match and as a result will be used for the issue creation.

if(fromAddress.getAddress() === "sender@test.com"){ result.setMatch(true); }

Match a keyword in the email subject using a regular expression

This script uses a Regular Expression to match a specific word within the subject. If found then it will match on this rule.

var regex = new RegExp("KEYWORD"); if(regex.test(subject)){ result.setMatch(true); }

Match a specific email address in all recipients

This Script check if there is a specific address within the full list of addresses include recipients. If the address is found then this rule will match.

Matching a Regexp against a specific Email Header value

This script gathers a specific header and it will compare each of the values against a Regexp and will set the rule as a match if the Regexp matches the value.

Updating Custom Field Values via Script

As with the Script Field Processor, the Script Rule also makes use of the resultMap object to allow update of Custom Field Values. Values are added to the Result Map in the Script rule will Overwrite any values already present in the resultMap.

Custom Field Keys vs Custom Field Names

JEMH Script rules and Script Field processors accept both custom field’s Name, and Keys in the resultMap, however we would recommend using the custom field Key where possible as the Key is Unique, whereas multiple custom fields can share the same name. Additionally, JEMH uses Custom Field Keys/Ids internally to track Custom Fields to prevent fields being overwritten (except for in Script Rules). If a Custom field name is used, a pre-existing field could be overwritten. For example, a custom field set via name in the Script Field Processor could be unintentionally overwritten by a Custom Field Default.