Inhibit notifications based on run-time conditions

Notifications can be conditionally prevented from being sent to Jira and Non-Jira user recipients. This is done by defining a Velocity macro (or “Velocimacro”) that is evaluated when an email template is being rendered.

The key part of the macro that stops a notification being sent is the invocation of the method:

1 $jemhUtils.setInhibitSending(true)

The velocity macro inhibitSendingConditions defined in JEMHC > Notification > Custom Macros is already called in all built in templates, so if you are using such a template already there is no need for additional template modification.

Testing with Preview Context data

You can and should test your custom Macro to be sure it works as a syntax error in this macro will break all notifications.

In order to test the User Macro, we need a Preview Context, which represents a notification of change from Jira for the kind of issue event to be inhibited. You can create a preview context from JEMHC > Auditing > Events (via cog drop down at the end of each line. NOTE: JEMHC will not retain event data from Jira in JEMHC > Auditing > Events without a matching ‘notification project mapping’ (JEMHC > Notifications > Notification Mapping > Email).

Basic example

For demonstration, the following macro will prevent notifications when the issue type is “Support”.

1 2 3 4 5 6 #macro (inhibitSendingConditions) ## macros are defined using #macro #if ($ == "Support") ## condition for $jemhUtils.setInhibitSending(true) ## this inhibits the notification inhibit ASOFT ## debug text only seen during preview #end ## ends the if block #end ## ends the macro definition
Previewing the basic example macro using previously encountered preview context data

If you use a different Preview Context, the scratchpad output will be updated, showing the different outcome.

Now we’ve shown how to inhibit ALL notifications for a given project, lets build that up, which involves you learning more about how to interact with the Preview Context, please read through:

If the configuration in Notification Mappings is not enough for your notification rules, you can define more complex conditions overriding a system macro. This macro has been included in all the templates.

  1. Enable Email users and JIRA users that you want to be notified in the project notification mapping: Notifications > Issue > Edit icon. Confirm the proper Target Audience has been selected.

  2. Add the inhibitSendingConditions custom macro in Notifications > Custom Macros > Edit. The following example uses the recipient type and the event data to only notify Bug issues to Email users (Jira users may receive any type of issues)

1 2 3 4 5 #macro (inhibitSendingConditions) #if ($jemhUtils.getRecipientType() == "EMAIL_CUSTOM_FIELD" && $ != "Bug") $jemhUtils.setInhibitSending(true) #end #end

If a notification has been inhibited for sending, you should see the following line in the event's report:

Restrict notifications to particular issue field changes

If you add the following Custom Macro to JEMHC > Notifications > Custom Macros, it will check a list of fields that are passed to it, and only allows notification if one of the listed fields was changed.  It also allows comments to be notified:

1 2 3 4 5 6 7 8 9 10 11 12 #macro (sendIfFieldChangeOrComment $fieldsToCheck) $jemhUtils.setInhibitSending(true) #set ($fieldChanged = false) #foreach ($item in $fieldsToCheck) #if ($jemhUtils.isCreateOrInChangeLog($context, $item)) #set ($fieldChanged = true) #end #end #if (($jemhUtils.filterRestrictedComments($context.comments).size()>0) || ($fieldChanged==true)) $jemhUtils.setInhibitSending(false) #end #end

To call the macro in your custom template, you need to add use something similar to the following example usages:

Checking 3 fields for changes: a custom field, the issues description field, and the issues status field:

1 #sendIfFieldChangeOrComment([ "Email Sender Address", "description", "status"])

Checking a single field for changes: the issues standard status field:

1 #sendIfFieldChangeOrComment(["status"])

Note the lowercase name for the standard issue fields.  The field names can be determined through viewing the webhook data for a previous event.