Use Directive Sets

@since 1.9.32

Introduction

Directive Sets are groups one or more pre-defined Directives that can be triggered by clicking a secure one-time link rendered in an email notification.

This allows simple and safe issue changes to be made by notification recipients without the need to write a reply.  These changes can be anything from simple custom field value changes, to more complex workflow manipulation.

The links generated only contain a security token.  No other parameters are present, meaning that the links can only be used for the intended purpose, one link per action.  A single notification email can have many of these links, allowing a choice of field values or actions to be made by the end user.

How it works

  1. An Issue Event occurs, rendering a custom Template Set (selected in the Event Listener).  As part of that template, unique links are rendered (see below for more information) for a specific Directive Set.  The notification is then sent to the recipient.

  2. The notification recipient clicks on a Directive Set link in the email

  3. The link sends a secure token to a JEMH REST endpoint that validates the token

  4. If the token is valid, the corresponding set of directives are sent as a Test Case to the configured To: address and profile for processing

  5. Once the processing has completed, a result screen to the user indicating if execution was successful or not. This result screen can be customized by creating and setting a Directive Set Render Result Template Set.

Notification templates

The DirectiveSetManager can be interacted with as $jemhDirectiveSetLinkManager below, to call createDirectiveSetLink (this comes pre-built into JEMH's global macros, the below code does not need to be added):

1 2 3 4 5 6 ## DirectiveSetLink support #set ($jemhDefaultDirectiveSetGroupId = $jemhDirectiveSetLinkManager.getDirectiveSetLinkGroupId()) #macro(generateDirectiveSetLink $label $runAsUserKey $directiveSetId $profileId) #set ($jemhDirectiveSetRestApiUrl= $jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhDefaultDirectiveSetGroupId, $runAsUserKey, $issue, $directiveSetId, $profileId) ) <A href="$jemhDirectiveSetRestApiUrl">$label</A> #end





We plan on eventually publishing our own Javadoc documentation. Please don't hesitate to ask us for help in the meantime!



The Parameters to this are as follows:

Example Variable

Example Value

Description

1 $jemhDefaultDirectiveSetGroupId

8f5f485b-7496-4f4b-a0fc-3e37269704bc

This is an id that is used to relate a set of links, such that when one link is used, the others are inherently expired/voided. An email may have several groups of links.

1 $runAsUserKey

andy

This is the ApplicationUser.getKey() value, e.g. $issue.getReporter().getKey() , the user will be the security context for the execution of the Directives. An email may have links with different context users.

1 $issue

its the issue from the event, $issue

The Issue object the event is about, if you're in a post-function, you'll have to get a reference to start with. The $issue may vary over links.

1 $directiveSetId

10

This integer value must refer a known ID value shown in the Directive Set section of the Event Listener. It refers to the set of Directives that will be applied.

1 $profileId

5

This integer value must refer a known profile ID value shown in the JEMH Profiles page. It will be the profile that will be used for processing the Directive Set defined in $directiveSetId, as the $runAsUserKey on the $issue

Terminology

Directive Sets

Allow users to perform defined Issue Directives by just clicking a link (called a Directive Set Link) generated in an email notification.  Directive Set's can be enabled or disabled - links will only be consumed if the parent Directive Set is enabled.

These are the hyperlinks that are associated with a Directive Set and are validated using single-use tokens, meaning that only recipients of the notification will be able to use the Directive Set.

Each link in a single outbound notification is put in a Link Group which is unique to that recipient.  Once a link has been processed by JEMH, it (and others in that link group) will expire.  If 30 days pass without a link from an individual notification being processed, then this will also cause all related links to expire.

Directive Sets use Directives, so make sure you understand how they work before attempting to use this feature. If changes aren't applied:

  • Check the JEMH Auditing > Report does not show any problems

  • Validate the Profile referred actually has Directives enabled, and the appropriate Field Processor for the body format used, e.g. AtPrefix (the example used on this page)

Example Scenarios

As a Directive Set can be configured with any valid Directive there are many ways that this feature can be used, here are just a few example scenarios:

Changing an issue Assignee

Lets say that you want a nice link in a notification that assigns the issue to the user Big Bob.

Create Directive Set

Go to the Event Listener tab in JEMH.  You should see a section called Directive Sets.  Select Create Directive Set.  You will then be taken to the creation screen:



Setting Name

Description

Status

The status that the Directive Set will be saved in.  If set to "disabled", subsequent links generated for the Directive Set will not be processed (but also not consumed).

Name

The name of the Directive Set.  This field is required, in order to help differentiate from others.

Description

A description for the Directive Set can be added.  This allows other administrators to understand its function.

To Address

Enter the address which the directives should be sent to in order to be processed. This should usually be a "catch email address" on the target profile.

Response TemplateSet

Allows selection of a template that will be used to render the response screen that a user is shown when they click on a directive set link. Information on creating these templates.

Directive(s)

The directive content to be executed.  It is recommended to enable the @prefix field processor, and use the respective format.  An example is given when creating each Directive Set.



We will set up our Directive Set as follows:

Select Create.  You will then be brought back to the main Event Listener page where you should see your new Directive Set:

Now we are going to add the link generating velocity macro to a custom notification template.

Go to JEMH>Template Sets.  Here, we will edit an existing custom template for the "Issue Created" issue event by selecting the edit action for the template.

The velocity macro that will be called is #generateDirectiveSetLink.  It needs 4 parameters in order to work, and the parameters must always be in the same order:

1 #generateDirectiveSetLink(LABEL,RUN AS USER,DIRECTIVE SET ID,PROFILE ID)

Parameter

Type

Description

Parameter

Type

Description

LABEL

String

The text that will show for the hyperlink in the notification.

RUN AS USER

String

The username of the JIRA user that the Directives will be sent by.  This needs to be a user who is allowed to perform the issue actions that the directive is for.

DIRECTIVE SET ID

Integer

The ID number of the Directive Set that this link is to be associated with.  You can find this ID number by going to the Event Listener>Directive Sets section and viewing the ID's in the first column.

PROFILE ID

Integer

The ID number of the target profile that will process the directives in the Directive Set.  The profile must be configured to have directives enabled, and the @prefix field processed enabled (if using the directive format in these examples).



For this example we are using the following:

1 #generateDirectiveSetLink('Assign To Bob','admin',41,26)

We are going to add the link in a row wrapper in this case, in order for the link to sit in the JIRA styled layout correctly.

Submit your changes to the template by pressing the "Submit" button.  Then, select the template for the corresponding event in the Event Listener Project Mapping, and save changes:

Validate Configuration

Now, when an issue is created, the notification recipients will get a notification with the Directive Set Link that we added to the template:

The recipient then clicks the link, and is taken to a page where they are given a response:

If you now check the issue, you will see that the assignee has been changed to the username defined in the Directive Set's assignee directive:

Implementing a Customer Satisfaction feature

If you have Jira Service Desk and want to get its built-in customer satisfaction feature working with JEMH notifications, see how to add customer satisfaction feedback to a service desk notification template.

For those who do not have Service Desk installed, a similar thing can be achieved using JEMH. In this scenario, we just show how to set a select custom field value, which will be done 'as' the user who is receiving the notification, whilst only one directive is shown, more could be added if needed.

Using a Select custom field, with values UNHAPPY, OK and HAPPY, we can create 3 Directive Sets, here using the AtPrefix Directive format:

Create Directive Set

This field has an ID of 10200, so can be selected as follows:

Apply Unhappy

Apply OK

Apply Happy

Apply Unhappy

Apply OK

Apply Happy

After creating, they are listed:

Setting up the template

Under Template Sets >User Macros, the following example velocity macro can be defined that in this case uses images stored on the Plugin People CDN:

1 2 3 4 5 6 7 8 9 10 11 12 13 ## ## example #generateCSAT('admin', 1, 1,2,3) ## arg1: userkey, arg2: profileID, arg3: unhappyDsId, arg4: okDsId, arg5: happyDsId ## #macro(generateCSAT $runAsUserKey, $profileId, $unhappySetId, $okSetId, $happySetId) <div> <B style="vertical-align:bottom;">How did we do?</b>&nbsp; #set ($jemhCSATDirectiveSetGroupId = $jemhDirectiveSetLinkManager.getDirectiveSetLinkGroupId()) <A HREF="$jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhCSATDirectiveSetGroupId, $runAsUserKey, $issue, $unhappySetId, $profileId)"><img src="http://cdn.thepluginpeople.com/prod/images/system/template/smiley_unhappy.png" title="Unhappy" style="width:32px;height:32px;"></img></a> <A HREF="$jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhCSATDirectiveSetGroupId, $runAsUserKey, $issue, $okSetId, $profileId)"><img src="http://cdn.thepluginpeople.com/prod/images/system/template/smiley_meh.png" title="ok" style="width:32px;height:32px;"></img></a> <A HREF="$jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhCSATDirectiveSetGroupId, $runAsUserKey, $issue, $happySetId, $profileId)"><img src="http://cdn.thepluginpeople.com/prod/images/system/template/smiley_happy.png" title="Happy" style="width:32px;height:32px;"></img></a> </div> #end

Template HTML for non Jira-users

This implementation of the above generateCSAT macro will only generate the customer satisfaction feature on the notification sent to the issue creator and can be invoked in a HTML Template Set as follows:

1 2 3 4 5 6 7 8 9 #if ($!recipientEmail && $recipientEmail == $issue.getCustomFieldValue("customfield_10301")) #set ($runAsUserKey = $issue.getAssignee().getKey()) #set ($profileId = 2) #set ($unhappySetId = 2) #set ($okSetId = 3) #set ($happySetId = 4) #set ($csatBody="#generateCSAT($runAsUserKey, $profileId, $unhappySetId, $okSetId, $happySetId)") #rowWrapperNormal($csatBody) #end

The field customfield_10301 is just an example - be sure to use the actual custom field ID of the field you are using to store non-Jira user addresses.

Template HTML for JIRA users

This implementation of the above generateCSAT macro will only generate the customer satisfaction feature on the notification sent to the issue reporter and can be invoked in a HTML TemplateSet as follows:

1 2 3 4 5 6 7 8 9 #if ($!recipientUser && $recipientUser.getKey() == $issue.getReporter().getKey()) #set ($runAsUserKey = $recipientUser.getKey()) #set ($profileId = 2) #set ($unhappySetId = 2) #set ($okSetId = 3) #set ($happySetId = 4) #set ($csatBody="#generateCSAT($runAsUserKey, $profileId, $unhappySetId, $okSetId, $happySetId)") #rowWrapperNormal($csatBody) #end

Combining the pieces of HTML and dynamically deciding which piece to use

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #if ($issue.getCustomFieldValue("customfield_10301") != $null) #if ($!recipientEmail && $recipientEmail == $issue.getCustomFieldValue("customfield_10301")) #set ($runAsUserKey = $issue.getAssignee().getKey()) #set ($profileId = 2) #set ($unhappySetId = 2) #set ($okSetId = 3) #set ($happySetId = 4) #set ($csatBody="#generateCSAT($runAsUserKey, $profileId, $unhappySetId, $okSetId, $happySetId)") #rowWrapperNormal($csatBody) #end #else #if ($!recipientUser && $recipientUser.getKey() == $issue.getReporter().getKey()) #set ($runAsUserKey = $recipientUser.getKey()) #set ($profileId = 2) #set ($unhappySetId = 2) #set ($okSetId = 3) #set ($happySetId = 4) #set ($csatBody="#generateCSAT($runAsUserKey, $profileId, $unhappySetId, $okSetId, $happySetId)") #rowWrapperNormal($csatBody) #end #end

The two pieces of HTML can be placed inside an IF statement that checks whether the custom field used to store the sender email address of a non-Jira user is null. If the field is found NOT to be null, then the template will execute the non Jira user HTML. Otherwise, if the field is found to be null then the Jira user HTML will be executed.

Use Template Set previews to generate test links that can be used to validate behaviour on the 'Preview Context' issue.

Here is an Issue Resolved Template Set with the macro call:

The preview (in context of Issue TEST-2), shows the section added:

Validate configuration

The hyperlink that is present on the notification should be similar to this format:

1 http://jira.example.com/rest/jemh/latest/public/directiveset/invoke?token=6e1e9d8fb70649fc81cd1c70ba1e33cc3db62add794146068ee83b17d435b9d6


When the link is opened, a simple success page should be shown:

Reviewing the issue screen, the field has been set, which now allows Dashboard Pie Charts widgets to be driven from this value:

Managing an issue workflow

This scenario shows how the Directive Sets feature can be used to make managing issue workflows with JEMH quicker and easier.  Check out the workflow below.  This could be a workflow for approval of user requests that require approval from 2 different people.  The issue might be assigned to a 1st line manager when it is first created.  That assignee will then either reject the request or approve it, assigning it to the 2nd manager for final approval:

We can make the task simpler by providing 2 hyperlinks in the notification that the manager receives - Approve or Reject.  We will focus on the "1st approval" to begin with.  We will first need to set up our directive sets, including workflow directives where appropriate:

Go to JEMH>Event Listener>Directive Sets and select Create Directive Set.  Set the status to enabled, add a name, description and add your directives.  The template set can be left as it is for now, we will show how these are added later in this guide.

Select Create.  You will now see your approval directive set.  Let's set another one up for the reject link:

Again, click Create to save the directive set.

Next step is Adding Links to the Velocity Script https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/114982925/Use+Directive+Sets#%5BhardBreak%5DAdding-links-to-Velocity-Script .

JSD Approvals

This scenario shows how the Directive Sets feature can be used to drive Jira Service Desk Approvals. Read more about Jira Service Desk Approvals here.
Firstly check which status/statuses are JSD approval statuses. Go to Project Setting > Issue Types > (Your Issue type with approvals configured) > Edit click on the status with approvals and check if the approvals have been configured as shown below:

Note that the status with Jira Service Desk Approvals in this example is called “waiting for approval” the status may be different depending on which status you have configured to have JSD approvals.
To create your Approved Directive Set go to JEMH>Event Listener>Directive Sets and select Create Directive Set and enter the directives shown in the screenshot below. 


Select Create.  You will now see your approval directive set.  Let's set another one up for the reject link:
Once the step below is complete move onto Adding links to Velocity Script Section

JSD Approvals with Post Function Notifications

Please note that If the custom field containing the approvers is a multi user picker then using Post Functions to drive JSD approvals isn’t the best way. The reason is currently JEMH Post Function messages do not send a unique email to each recipient like the JEMH Issue Event Notifications but instead adds each recipient to a single email. In this case It is best to use custom event in conjunction with JEMH Notifications as described in this section.

Please follow the previous section which sets up the directive sets to be used in your template set or custom velocity context. Ensure that the transition where the post function is set is a transition leading to the Approval Status as shown in the example below:

In this example the approval status is called the “Waiting for approval”. The transition we are focusing on in this example is the “Create Issue” transition where the Post Functions should be set.

JSD Approvals Custom Issue Event for Multiple User Picker

In this section we will explore how to handle a multi-user approvals. Please make sure that you have done the pre-requisites for this section namely configuring your JEMH Issue Event Notification as documented in https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/70844484/Send+notifications+for+Issue+Events and additionally setting up the directive sets mentioned previously in https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/114982925/Use+Directive+Sets#JSD-Approvals .

Firstly you will need to create a custom event that will be fired to do this go to Administration > System > Events and Add a new custom event.

Then you must edit your custom event notification entities in the notification scheme which you have configured in JEMH Configuration > Notifications > Jira user notification Project Mapping > Notification Scheme which can be edited in Administration > Issues > Notification Scheme and click Notifications on the configured Notification Scheme.

Then add your custom field which contains the user entities to the Custom Event Notification Scheme (in this example the custom event is called “Second Approval”) and ensure that these are configured as a “User Picker (multiple users)” field you can do this by going to Administration > Issues > Custom Fields.

Please note that you should only add the custom field that contains users who are responsible for 'authorising' as by default the every user configured will receive the approval notifications.

 

Go to Project Setting > Issue Types > (Your Issue type with approvals configured) > Edit click on the status with approvals and check if the approvals have been configured as shown below:

Then ensure the correct custom field is set for your approvers.

click on the transition before the status with approvals and navigate to the Post functions screen:


On the Post Function screen set the Event to be your Custom event to replace the “Generic Event” in this example.

 

Then you must create a template set for your custom event in JEMH Configuration > Template Sets

After you click the Create button then you must add your velocity link as described in https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/114982925/Use+Directive+Sets#Adding-links-to-Velocity-Script . The caveat being the run as user key id will be the recipient user as the appropriate users will be notified as we set up previously. In you template set HTML section you will the following velocity snippet to retrieve the current recipient key and use the user key as the run as user. For information on how to use Template Sets please refer to https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/2850840 and how to customise the content of Template Set using velocity please refer to https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/2850876/Customize+Email+Templates#:~:text=JEMH%20exposes%20JIRA%27s%20notification%20templates,of%20your%20entire%20template%20collection. .

1 #set ($userKeyId = "$recipientUser.getKey()")

In your velocity you need to replace your run as user id with the variable above (the snippet below is an example please refer to https://thepluginpeople.atlassian.net/wiki/spaces/JEMH/pages/114982925/Use+Directive+Sets#Adding-links-to-Velocity-Script on how to set up your link)

1 #rowWrapperNormal("#generateDirectiveSetLink('Approve', $userKeyId ,3, 1) ")


Then in JEMH Configuration > Notifications > Jira user notification Project Mapping > Event Template Selection set the template to be your custom template set.

 

Now, we add the velocity script to our "Issue Created" template set that provides the 2 links:

Go to JEMH>Template Sets and edit/create the template.  The velocity script needed is of the following format (note that this is for generating 2 links):

1 #generateDirectiveSetLink(LABEL,RUN AS USER,DIRECTIVESET ID,PROFILE ID)

Parameter Name

Description

Parameter Name

Description

LABEL

This parameter is the text that will show for the hyperlink in the notification.

RUN AS USER

This is the username of the Jira user that the Directives will be sent by.  This needs to be a user who is allowed to perform the issue actions that the directive is for. In later versions of JEMH this will need to be the user key instead of the username you can retrieve the user key by the velocity context for example using the userManager: $userManager.getUser('username').getKey() .

DIRECTIVE SET ID

This needs to be the ID number of the Directive Set that this link is to be associated with.  You can find this ID number by going to the Event Listener>Directive Sets section and viewing the ID's in the first column.

PROFILE ID

This needs to be the ID number of the target profile that will process the directives in the Directive Set.  The profile must be configured to have directives enabled, and the @prefix field processed enabled (if using the directive format in these examples).

If your template is based off the built in JIRA style, you will most likely want to add the links within a "row wrapper" in order for them to not break the notification styling:

1 #rowWrapperNormal("#generateDirectiveSetLink('Approve','admin',45,26) | #generateDirectiveSetLink('Reject','admin',46,26)")

Submit your changes to the template.  Make sure that the custom template is selected for desired event.  In this example scenario we have chosen the "Issue Created" event.

Testing

On issue creation the assignee gets a notification with generated links:

In this example scenario, the manager was not keen on the giraffe being brought to the office.  On clicking Reject they are shown a response screen (below, default response template is used):

If we take a look at the issue, we can see that the directive has been successfully processed and the issue has been transitioned to the "Rejected" status:

Customizing the link presentation

Links can be replaced with other elements, such as buttons. See the Atlassian User Interface documentation for more information. As an example:

1 2 3 4 #macro(generateDirectiveSetButton $label $runAsUserKey $directiveSetId $profileId, $isPrimary) #set ($jemhDirectiveSetRestApiUrl= $jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhDefaultDirectiveSetGroupId, $runAsUserKey, $issue, $directiveSetId, $profileId) ) <A href="$jemhDirectiveSetRestApiUrl"><button class='aui-button #if ($isPrimary==true)aui-button-primary#end'>$label</button></A> #end

Which can be invoked with (here, when status is In Progress)

1 2 3 4 #if ($issue.getStatusObject().getName()=='In Progress') #set ($approveDeclineBody="#generateDirectiveSetButton('Approve (resolve issue)', $issue.getReporterId(), 3,9, true) &nbsp;&nbsp; #generateDirectiveSetButton('Reject (stop progress)', $issue.getReporterId(), 4,9, false)") #rowWrapperNormal($approveDeclineBody) #end

When rendered, looks like:

Use in workflow

Combining the button example above, Here is a simple HTML template that could be used as the basis of a JEMH Workflow drive approval request

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <html> <body> <h3>Approval Required</h3> <p>Your action is require to approve or decline $issue.getKey(), the last comment was:</p> <div> <quote> $wikiRenderer.render($comment.getBody(), null) </quote> </div> <BR/> <div> #if ($issue.getStatusObject().getName()=='In Progress') #set ($approveDeclineBody="#generateDirectiveSetButton('Approve (resolve issue)', $issue.getReporterId(), 3,9, true) &nbsp;&nbsp; #generateDirectiveSetButton('Reject (stop progress)', $issue.getReporterId(), 4,9, false)") #rowWrapperNormal($approveDeclineBody) #end </div> </body> </html>

Such a notification would look like:

Adding a custom response template

By default, JEMH will use its own built in template.  A custom template can be created, by going to JEMH>Template Sets and clicking the Directive Set Response tab.  Then, click the + add button to create a new template.  Click the pen icon  to edit the template.

HTML Content Only

Please note that the response template can only contain HTML content.

Advanced configuration

Enabling Directive Sets for recipients without direct Jira network access

 Since JEMH 3.0.0, 2.7.16+

When recipients don't have direct network access to Jira, the Directive Set approach above clearly won't work (it uses full URL's). So, in this variation we change how this works:

  • we generate mailto: links instead of direct http: links in the initial outbound email, to reply the required Token in the subject of the email

  • we add some detection code in the Script Field Processor, identify such email and extract the token.  Then, we invoke the REST URL 'anonymously' jsut as if the remote user had clicked on it directly.

In the outbound notification, use a mailto: instead of using a direct http URL, with a modified macro:

1 2 3 4 5 6 #macro(generateDirectiveSetButton $label $runAsUserKey $directiveSetId $profileId, $isPrimary) #set ($jemhDirectiveSetRestApiUrl= $jemhDirectiveSetLinkManager.createDirectiveSetLink($jemhDefaultDirectiveSetGroupId, $runAsUserKey, $issue, $directiveSetId, $profileId) ) #set ($subIdx = $jemhDirectiveSetRestApiUrl.indexOf('token=')+6) #set ($mailTo = "blah@blah.com?subject=JEMH Automation - "+$label+" - JEMH_TOKEN=$jemhDirectiveSetRestApiUrl.substring($subIdx)") <A id="jemh-ds-$directiveSetId" href="mailto:$mailTo"><button class='aui-button #if ($isPrimary==true)aui-button-primary#end'>$label</button></A> #end

Sot the template script looks something like

1 <A HREF="mailto:mailbox@yourco.net?subject=JEMH Automation - JEMH_TOKEN=$jemhDirectiveSetRestApiUrl.substring($jemhDirectiveSetRestApiUrl.indexOf('token=')+6)">Approve</A>



The recipient user will now be able to click approve/decline links which send the token in the subject back to Jira - it goes without saying that the mailbox must be processed by JEMH, leading into the next part.  The email text is shown here for illustration (end users wont see this!)

1 2 3 4 5 6 7 8 9 10 MIME-Version: 1.0 Received: by 10.223.112.12 with HTTP; Sat, 18 Jun 2011 22:42:26 -0700 (PDT) Date: Sun, 19 Jun 2011 17:42:26 +1200 Message-ID: <BANLkTinB1mfSh+GwOXGNWoL4SyDvOpdBoQ@mail.gmail.com> Subject: JEMH Automation - JEMH_TOKEN=dc99e9064ff9416ea33082c7dc4283d9529565e1261b4dfda3b9981bbcf70ee6 From: reporter@test.com To: changeme@thiswontwork.com Content-Type: text/plain; charset=UTF-8 this text will be ignored (currently)

The Magic: use a custom Script within the Script Field Processor

Here we will scan the email for the required token prefix, and if found extract, and actually invoke the URL locally via jemhUtils.invokeLocalRest('/rest/....').  If it all works out, we will also indicate that the mock email that JEMH is currently processing can be dropped silently, as it would otherwise create issues for no reason.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 print('hello world, below you can see some of the variables available in the rule context'); print('message obj is '+message); print('subject is '+subject); if (subject.indexOf('JEMH_TOKEN=')!=-1) { resultMap.put("FORCE_JEMH_SCRIPTFP", true); //force the Script Field Processor to 'own' this message print('token bearing email found'); var token=subject.substring(subject.indexOf('JEMH_TOKEN=')+11); var path = '/rest/jemh/latest/public/directiveset/invoke?json=true&token='+token; var response = jemhUtils.invokeLocalAnonRest(path); if (response.has("success") && response.get("success").equals("true")) { print('DirectiveSet processing success'); print('--\n'+response+'\n--\n'); if (response.has('issue')) { print('issueKey: \n'+response.get('issueKey')); } if (response.has('name')) { print('directiveSet Name: '+response.get('name')); } if (response.has('description')) { print('directiveSet Desc: '+response.get('description')); } if (response.has('directives')) { print('directives: \n'+response.get('directives')); } jemhUtils.dropMessage('DirectiveSet mail automatically consumed'); // JEMH should not process the message, the message should be deleted silently from the mailbox } else if (response.has('jemhError')) { print('failed: '+response.get('jemhError')); jemhUtils.forwardMessage('DirectiveSet mail failed to be consumed due to error: '+response.get('jemhError')); // JEMH should not process the message, send to the 'forward' address, and delete the message from the mailbox } else { print('unknown response:\n'+response); jemhUtils.forwardMessage('DirectiveSet mail failed to be consumed, unknown reason'); // JEMH should not process the message, send to the 'forward' address, and delete the message from the mailbox } }

Some explanatory screenshots:

The defined Directive Sets in my example:

The notification with the styled button

The mail received by JEMH

1 2 3 4 5 6 7 8 9 10 MIME-Version: 1.0 Received: by 10.223.112.12 with HTTP; Sat, 18 Jun 2011 22:42:26 -0700 (PDT) Date: Sun, 19 Jun 2011 17:42:26 +1200 Message-ID: <BANLkTinB1mfSh+GwOXGNWoL4SyDvOpdBoQ@mail.gmail.com> Subject: JEMH Automation - JEMH_TOKEN=6b014e4fffd24906b8436fe53e23a853e1449aee5d4446ebb9a3ea438ab6b9c4 From: doesntmatter@test.com To: changeme@thiswontwork.com Content-Type: text/plain; charset=UTF-8 Some example text

Test Issue prior to Directive Set

Test Issue post Directive Set execution

Showing the outcome of running the Directive Set to update the issue:

And if you do some testing within the Script field prod dynamic evaluator against a Test Case

If the Directive Set key cannot be found (e.g. its used/expired) you'll see:

Related Articles