Email Notification Schemes are rules to send notification emails upon changes made to issues. They are similar to Jira Notification Schemes in this context, but Email This Issue Notification Schemes provide a lot more compared to standard Jira features.
You can add multiple Email Notificaiton Schemes in JETI. The list of Notification Schemes is accessible from the Email / Notification Schemes menu.
If an event occurs, Email This Issue selects the best matching Email Notification Scheme to send notifications.
To find the best matching Email Notification Scheme, the scheme's Projects, Issue Types and JQL Filter settings are used. These are called Scope.
The scope determines to which issues an Email Notification Scheme is applicable. If there are multiple schemes in the system, Email This Issue evaluates all of them and determines the one with the best matching scope for the issue that the users want to send in emails.
The scope may be composed of:
- 0 or more projects
- 0 or more issue types
- An Optional JQL filter query
To enter a JQL which involves a user name (such as defining the assignee of an issue), follow the below steps:
- Under the JQL field, click Edit
- Enter the JQL as usual
- When it comes to entering a username, search for it, then click on Insert user
- Click Save to use the JQL or click Cancel to delete it
Email Notification Schemes are essentially useless without Email Notifications. Email Notifications are the rules for sending emails. They are defined by three main aspects:
- WHEN or events and filters
- WHO or recipients.
- WHAT or content settings
An Email Notification Scheme may contains multiple Email Notifications, event for the same event types. Email This Issue will find the best matching rule for an issue to send emails based on the Events and Filters set in the Email Notifications.
Events and Filters
The Events and Filters of an Email Notification determine when emails must be sent out for an issue. may be defined by the following fields:
|Events||Event types selected. Mandatory.||This field selects the Jira event types upon which the Email Notification rule will send emails.|
|Event's trigger||created events|
- In Jira web interface/Customer portal
- By mail handler
|If there is an issue created event in the events list, then you can decide when you want to listen on these events.|
- Jira web interface
- manual email
- Mail hanlder
|If there is a comment related event (eg. Issue commented, Service Management Public Comment added, ...) in the events list, then you can decide when you want to listen on these events.|
|JQL Filter||Valid JQL query. Optional.||This is a filter. If specified, issues must match the criteria otherwise the Email Notification rule is ignored and emails not sent|
|Fields||Issue fields or custom fields selected. Optional|
If specified, Email This Issue will send emails only of the selected fields have been modified in the issue during the operation that resulted in the event.
This Email Notification rule will be applied if Issue Updated or Issue Commented or Issue Moved events are fired AND the issue is of priority Highest AND attachments are added during the operation.
Recipients selected here will receive the event notification emails.
Emails may have To, Cc and Bcc recipients. For all of these recipient types you can enter or select:
- users from Jira
- email addresses
- Persons related to the issue or project: Assignee, Reporter, Watchers, Project Lead, Current User
- Project Roles
- User Groups
- Custom Fields that may hold email addresses or users or groups
The available user groups, project roles and custom fields may be limited in the Recipient Restrictions. This is useful for example if you want to avoid users accidentally selecting "jira-users" group as a recipient and hence sending emails to all users.
Content settings in Email Notifications specify the Customizable Email Templates to use, and additional content that will be added to the email.
Content Settings attributes include:
|Template||An Email This Issue Template||The template selected here will be used to render the subject and body of the final email.|
|Subject||Text to be added to the email subject|
Text entered here will be combined into the final email's subject using the template above.
The template's $!mailSubject variable renders the entered value in the email subject
|Message||Text to be added to the email body|
Text entered here will be combined into the final email's Body using the template above.
The template's $!mailBody variable renders the entered value in the email body
The value selected in this field determines which issue attachments should be attached to the email.
- all: all attachments added
- none: none of the attachments added
- newest versions of all: newest version of all attachments. Attachments having the same name are considered versions of the same attachment.
- added recently: latest added attachments (Actually since we don't get any list about the added attachments, we have to figure out the latest added attachment. For this we ask for all the attachments of the issue and send only added at the last minute from the latest one.)
- The newest attachment(s) in the issue: the last added attachment(s)
Additionally, you can configure the policy to filter internal attachments. When this option is enabled and the issue is in a Service Management project, then the attachments that were added via internal comments will not be included in the email.
|Email Format||HTML or TEXT||The format of the email to send.|
Additional settings offer a few options:
- Include Own Changes: if the current user is a recipient, use this option to send her a notification regardless of her profile setting "My changes: do not notify me". If disabled, Email This Issue will respect the profile setting.
- Add current comment to email body: if enabled and comment is available, it will be appended to the email body