...
| Info |
|---|
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”.
...
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.
...
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:
| Code Block |
|---|
#sendIfFieldChangeOrComment([ "Email Sender Address", "description", "status"]) |
Checking a single field for changes: the issues standard status field:
| Code Block |
|---|
#sendIfFieldChangeOrComment(["status"]) |
| Note |
|---|
Note the lowercase name for the standard issue fields. The field names can be determined through viewing the webhook data for a previous event. |
Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|