Use Script Field Processor
- 1 Introduction
- 1.1 Supported scripting languages
- 1.1.1 Groovy
- 1.1.2 Graal
- 1.1.3 Selecting a Scripting language
- 1.1 Supported scripting languages
- 2 Enabling the Script Field Processor
- 3 Editing the Script
- 4 Example
- 4.1 Email Test Case
- 4.2 Example Script
- 5 Forcing the Script Field Processor to be active always
- 6 Auditing
- 7 Stopping excess logging about Nashorn deprecation
- 8 Useful references
- 9 How we support this
- 9.1 Future Features
- 10 Related articles
Introduction
since 2.5.2 (Minimum Jira 7.7.x)
When JEMH Processes messages, the content (subject/body) can be subjected to Field Processors, which are specialized parsers. Other examples of Field Processors are the AtPrefix format, which parses out @key=value combinations from the email body lead in. These keys are Supported fields for use with Directives, and allow Email content to drive issue updated during create and comment, even workflow transitions. The script field processor is the final piece in the puzzle for customization processing of content, until now, new 'custom' processing could only be achieved with add-ons for JEMH, which are a technology hurdle too far for most. With the new Script Field Processor, basic knowledge of JavaScript and this how to guide will be enough to have you running in no time!
Supported scripting languages
In theory, any language with a JSR-223 compliant engine can be used. ECMAScript (JavaScript) is supported by default through the Nashorn script engine at present, but this has been deprecated for final removal in JDK 14. To install additional Scripting languages see: Install a Scripting runtime Engine (Nashorn, Groovy, Graal)
Groovy
Apache Groovy – Typical installation involves dropping the embeddable Groovy .jar file into JIRA_INSTALL/lib. If ScriptRunner is installed, the Groovy engine from that will be used.
For a guide on installing Groovy see: Install a Scripting runtime Engine (Nashorn, Groovy, Graal) | Groovy
Graal
since 3.3.18 (Minimum Jira 8.0.x)
GraalVM is a full virtual machine in its own right, a component of which is the Graal Script Engine, which can be dropped into existing Java Virtual Machine installations to enable it to be used in place of Nashorn. By not bundling the script runtime we (a) reduce memory footprint of our app, by deploying Graal ScriptEngine into Jira or your Java Runtime, it is then available for other apps to use, (b) we do this to not exclude other 3rd party apps from making use of the script engine as incompatibilities will arise if apps include script engines.
For a guide on installing Graal see: Install a Scripting runtime Engine (Nashorn, Groovy, Graal) | Graal
Selecting a Scripting language
This should now be a simple select (each scripting language is prefixed with it relevant name (to make the Engine source more clear e.g. Graal.js) comes in with JEMH 3.3.13 (Jira 8.0+)
Enabling the Script Field Processor
Edit your JEMH Profile, and then edit the Field Processors section:
Check the box for the Script Field processor and submit:
Once the Script Field Processor has been enabled, it will be shown toward the bottom of the main profile screen. It can be expanded to preview its configuration. To start with, it show an example configuration:
Enable Directives
Field Processors require Directive Processing to be enabled on the Profile. Go to the Profile > Directives section and set the Directive Processing Behaviour to be something other than disabled. You can expand the Directives section by clicking on the left hand side arrow, shown below:
This setting is primarily required for other Field Processor types where users can supply content than can update issues. If you have other field Processors active, it will already be on, if after enabling the Script Field Processor you enable other Field Processors, be aware that this can be a security risk in some situations.
Editing the Script
Once enabled, the way to get to the Script Field Processor editor is at the bottom of the Profile > Summary screen.
Using the pen icon on the Script Field Processor section you will get to the Script Field Processor editor screen:
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.
Key to image above
| Section | Description |
---|---|---|
1 | Language selection | The Language picker defaults to the ECMAScript implementation which is bundled with the Oracle JRE. It is possible to add more scripting engines such as Groovy, by adding its embeddable distribution JAR to the Tomcat or Jira class path, e.g. JIRA_INSTALL/lib. |
2 | Description | A description will help you and others remember what the purpose of this script is. Its also possible of course to add code comments within the script, shown later. |
3 | Context | This shows the variables you have access to within the script, for example, if your script contained print('subject is : '+subject); then, the email subject would be added to the console. The resultMap reference has a special use. Its purpose is to hold the field values that you wish to be set. Keys in the map should match Supported fields for use with Directives. Values should be appropriate and formatted as needed (usually text values are fine). |
4 | Script Editor | The editor enables manipulation of the script content. |
5 | Test Case selection | Allows selection of a Test Case to be used during in order to provide email-specific context data, such as subject. |
6 | Test run button | This button is used to execute the script with the selected test case email. |
7 | Test results | Once the test is completed, test results will be displayed. This will show mapped values for use in issue creation/update, and any debug log output: |
Example
Forcing the Script Field Processor to be active always
When an email is processed, the enabled field processors within the related Profile all take part in an election process to determine which set of output should be used. Its possible that you may want the Script processor to be active for a given message, this can be forced with the following:
resultMap.put("FORCE_JEMH_SCRIPTFP", true);
Auditing
If you have auditing enabled (shown below), you'll find a transcript of the Script Field Processor output, along with the detail of what fields (key value pairs) were extracted by it, the way to get at the detail is through the highlighted icon bottom right, accessed by hovering on the auditing row.
An example of the detail generated by the Script Field Processor is shown below which shows the debug log from the script execution.
Stopping excess logging about Nashorn deprecation
The Nashorn javascript engine is bundled with JDK8 though JDK11 but was removed in JDK15, so will not be available in JDK17 (an open source nashorn library can be used, as well as an alternate Graal engine, for more info see: Install a Scripting runtime Engine (Nashorn, Groovy, Graal) ). Jira logs may report this deprecation many times, to disable this deprecation notice, add the following as a JVM ARG (Setting properties and options on startup | Administering Jira applications Data Center 10.1 | Atlassian Documentation ).
Useful references
Methods available to operate on the body content which is a Java type String, see Oracle JRE String class documentation for available methods (e.g. body.toLowerCase() , body.indexOf("bla") etc).
Mozilla JavaScript landing page and JavaScript reference
JavaScript language (spec)
How we support this
We have provided a script capability for Field Processors, and also for Project Mapping Rules. There is no end to the variability of how these features can be used, and for your requirements. To prevent our support system from getting completely jammed, we cannot provide implementation or debugging support for your scripts. If the scripting side of this is too complex, then you should approach a trusted Atlassian Partner who can support your efforts.
Future Features
Its quite likely that in order to maximize your ability to solve a particular problem, that it would be very useful for X to be available in the context, or utility feature Y to be made available. Feel free to ask through our SUPPORT mailbox (support@thepluginpeople.com), no guarantees - we want to keep the Field Processors and the context as streamlined as possible.
Related articles