How Jira events turn into emails

This page covers how change in Jira issues result in email notifications that consume your JEMHC plan message capacity.

 

Issue event data sent by Jira

When changes are made to your Jira issues, they trigger webhooks (JSON data) to be sent by Jira to JEMHC. These webhooks contain information about the changes that have happened.

Once JEMHC has received the webhook, the event data is then securely queued for processing. The app takes the queued data, performs some processing on it, and then stores this data for processing under the following conditions:

  • A valid license is present (once a subscription is active, cancelling it and starting a new trial will not work). To determine the app’s current license status, go to Jira settings > Apps > Manage apps and expand the JEMHC entry.

  • A Notification Mapping for the related project (or for all projects) is configured in the app. This can be determined by navigating to JEMHC > Notifications. For example, here is an email mapping:

Jira bulk changes

When a bulk change happens, your Jira instance will send a webhook for each and every issue update. This can create a flood of notifications if you check “Send mail for this update”. After many years of lobbying, Atlassian finally included this flag in the webhooks we receive.

By default, “Send mail for this update” is unchecked, meaning JEMHC will drop the webhook as soon as it is received, no mail will be sent. If “Send mail for this update” is checked, a notification webhook will be sent for every transition made against every selected issue.

Why Jira still sends all your issue data to us when no JEMHC license is present

Due to long standing open issues on the Jira platform, regardless of your license state, if the JEMHC app is still installed, JEMHC receives ALL webhooks for ALL projects. If you have unlicensed JEMHC and no longer wish your data to be sent to us, you should uninstall the JEMHC app in addition to unsubscribing.

Email notification mappings

The JEMHC > Notifications > Email mappings are where the fine detail of ‘how’ recipients are resolved, how the mail is sent, and attachment control is.

There are many settings for notification mappings. Here are some of the key ones:

  • Event template selection - controls which of the 3 main event types are to be notified for

    • Issue created

    • Issue updated

    • Issue deleted

  • Project selection - choose one or more projects that the mapping applies to. Can be set to apply for all projects.

  • Recipient type - determines whether emails are set to recipients as BCC to reduce message usage, or as TO, which means each recipient gets a separate notification.

  • Audience - controls who is notified of the events

    • Standard issue fields such as Reporter, Assignee etc.

    • Custom fields (text and user types)

Scenarios

This scenario will show simple Issue creation by a Jira user/portal user without attachments/images. To review other scenarios with different events, please refer to https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/2666725387.

Notification Mapping configuration

The following notification mapping configuration has been used:

Additional settings which are not present in above screenshot:

  • Recipient Type: - Bcc

Issue Creation

Issue

Issue History

Issue

Issue History

 

 

Jira sends a Webhook sent to JEMHC, where it will be stored if the license is valid and there is a Project Mapping for the related project (or all). The [1] in the screenshot below indicates the number of webhook events we received/merged which is how JEMHC will ‘batch’ multiple events in a minute window together to reduce email volume, and maximize Plan allocation usage.

Events stored by JEMHC are shown in Auditing > Events, each event has some context options available, Run will cause the event(s) to be consumed immediately, the event can be deleted, we can save a copy of the event as a Preview Context (for template preview or exported for support purposes:

Event Processing

After a minute, events received in the last minute for each issue are processed, the event is updated to indicate what notifications were sent (here, slack and email), see the Report from the context menu for more info:

The Auditing > Outbound Messages view shows a filtered view of all notifications ( the default is SMTP, so other variants such as Office365 EWS (Exchange Web Services) are not shown by default, select Type: All to see all kinds of notifications, here, we can see the recent Slack and email


Each items has a context menu accessed through the cog on the right. From the email item:

The Report will indicate who was notified, along with the outbound sender (From) address:

A restricted view of the mail is also available, so you can see ‘what’ content was sent (and see it differ between different recipient notifications):

 

Reviewing the actual sent mail

The received mail would look appear as below, many common images (include the Plugin People logo bottom right, are referred via our CDN, so cost nothing in terms of data. If you were to examine the source of the sent mail, the small image likely present relates to the user avatar image, which is inlined in the mail.

Querying mail sent through the Analysis feature


Available through Auditing > Analysis, we provide the ability to query mail received/sent in various ways. For example here, we can set the “Issue Key” to be JEMHCTEST-2, and set the Group By to be “Type”, which shows the Message Size and the data used (deducted from the Plan capacity). Instant Message notifications are free (do not count toward Message volume or Data usage).

If you went back the the Outbound Message Auditing view, you could export the mail, and check its file size:


You can see that the size of the physical email is larger, this is because of additional email headers that were involved, but we don't consider this for data usage, hence the smaller number should via Analysis relating to the content + attachment data size prior to encoding. There is always a slight difference in outbound notification ‘size’ actually and what JEMHC deducts, its done prior to encoding for simplicity.

Monitoring Usage

The Licensing > Usage shows a live usage summary of message volume and data.

JEMHC can also notify you of relative usage (via Usage notification warning threshold % ), whereby if this value was 50%, and you were notified of this earlier than the middle of the month, on balance, capacity looks to be enough, if you get this on day 1, its probably not going to last much longer. Recipients are listed through Licensing > System Notifications > (Email Addresses | Users).

Usage notifications do not count toward your message volume or data plan as they are sent through our noreply@thepluginpeople.com system mailbox.

Related articles