Create a custom Field Processor

Owned by Andy Brook [Plugin People] (Unlicensed)
Last updated: Jan 26, 2024 by Finn Gale
5 min read

Scenario

Even with the default Field Processors, you have content and/or customized issue creation logic that you want to manage.

Solution

You need to write a custom third party Field Processor,  the hooks are there, though documentation is limited.  This approach should only be taken be developers with some Java experience!



Example Walkthrough

Assumptions here are that you have some experience with Atlassian SDK, I wont talk of tools, maven etc, just the nitty gritty.

Deploy dependencies into you local repository

JEMH doesn’t push API jars into a public repository yet - pull one out of the jar:



wget -nd https://marketplace.atlassian.com/download/plugins/com.javahollic.jira.jemh-ui/version/100508310 -O jemh.jar

Unpack the jar in a temp folder (jar xf jemh.jar) and go to the META-INF/lib subfolder.  Deploy the API jar as follows:

 You will need to be able to extract the jemh-api and jemh-ao JARs from your target JEMH JAR (this should be published to a central repo, hasn't happened yet though), and deploy to your local maven repository (see how)

andy@sol:~/workspaces/javahollic/jemh-example-extensions/field-processor/x/META-INF/lib$ mvn install:install-file -Dfile=jemh-api-1.1.63.jar -DgroupId=com.javahollic.jira.jemh -DartifactId=jemh-api -Dversion=1.1.63 -Dpackaging=jar [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Stub Project (No POM) 1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom --- [INFO] Installing /home/andy/workspaces/javahollic/jemh-example-extensions/field-processor/x/META-INF/lib/jemh-api-1.1.63.jar to /home/andy/.m2/repository/com/javahollic/jira/jemh/jemh-api/1.1.63/jemh-api-1.1.63.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.387s [INFO] Finished at: Fri Jun 13 14:05:35 BST 2014 [INFO] Final Memory: 5M/240M [INFO] ------------------------------------------------------------------------

And then the AO JAR (this will go away at some point)

andy@sol:~/workspaces/javahollic/jemh-example-extensions/field-processor/x/META-INF/lib$ mvn install:install-file -Dfile=jemh-ao-1.1.63.jar -DgroupId=com.javahollic.jira.jemh -DartifactId=jemh-ao -Dversion=1.1.63 -Dpackaging=jar [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Stub Project (No POM) 1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom --- [INFO] Installing /home/andy/workspaces/javahollic/jemh-example-extensions/field-processor/x/META-INF/lib/jemh-ao-1.1.63.jar to /home/andy/.m2/repository/com/javahollic/jira/jemh/jemh-ao/1.1.63/jemh-ao-1.1.63.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.400s [INFO] Finished at: Fri Jun 13 14:06:27 BST 2014 [INFO] Final Memory: 6M/303M [INFO] ------------------------------------------------------------------------

Clone the extension project

There is a test project out at https://bitbucket.org/pluginpeople-public/jemh-example-extensions/src/master/ clone that locally:

git clone git@bitbucket.org:pluginpeople-public/jemh-example-extensions.git



The source code has had some branches added to help developers get a more consistent set of code:

  • jemh-1.9.x

  • default (jemh 2.0.x)

Switching branches

Mercurial (yea, should use GIT, historical bias).  To switch to a new branch use hg update -r <branchname>, for example:

Deploy the parent pom to your repository

In the jemh-example-extensions/example-parent folder, run the following to deploy the parent pom

Build the example field processor

In the jemh-example-extensions/field-processor folder, run atlas-mvn clean install to build and deploy:

Load the addon into JIRA

Via the Manage Addons screen in JIRA, as an admin use the Upload addon button:

Navigate and select the jemh-example-extensions/field-processor/target/example-jemh-field-processor-1.0.jar file, upload to see:

Great!

Check JEMH sees the addon

Ever looked into the JEMH Exetensions tab?  Well now's your chance, scroll down to Field Processors, see the new Mystery Field Processor!

Configure JEMH to use the new field processor

Creating a new profile, the Mystery Field Processor is listed in the third party field processors selector:

Edit the enabled field processors and select the Mystery Field Processor in the 3rd party selector.

After submission, it will be listed:

Testing the custom field processor

In this example, custom handling is done based on the from: address  matching jemhtestfp@localhost.localdomain: , be sure to pick the right profile!

Running the test case against the profile then results in the following indicating which processor ran:

Drilling into the issue we see that, OH NO! our issue has been Encheferized!



Natural follow on questions and answers:

  • It doesn't work.  Mmm, try again, really, I just did this , cursory directions can be asked for but development support is a consult and is chargeable. Note: for now, you may need to re-install pluggable extensions manually if JEMH is updated.

  • No, development support and debugging 3rd party code is not part of product support, it is a consult, and is chargeable.

  • No, source code is not automatically available to licensees.  I'm deliberately making it difficult to obtain, a paid license is required for that, and decompiling is against the EULA mmkay?

  • Maybe, if you produce a field processor it could be freely given to be included in JEMH.  There is no obligation on our part to accept or to commit to any particular adoption timeline.  The less configuration code needs to be 'added' the more likely it is to be adopted.