Contexts

Contexts connect various configurations and settings to a scope. The scope of a context can be composed of:

  • A project (optional)

  • An Issue Type (optional)

  • A JQL filter (optional)

The scope determines which issues the Context is applicable for. These are displayed in the Contexts menu in an expandable list.

Context attributes

Context attributes have the following main aspects:

  • The scope for which the context is set (project/issue type/JQL)

  • The content that is applicable to the scope

  • The Email This Issue notifications applicable to the scope

  • Additional settings within the scope

Adding a new context

To create a new Context do the following:

1. Go to OUTGOING EMAILS --> Contexts.

2. Click the Add button.

Scope

The scope maps all the context settings to a certain project/issue type/JQL or a combination of these.

AttributeDescription

Project

Defines the project to which the context is applied. Applied to all projects if left empty.

Issue Type

Defines the issue type to which the context is applied. Applied to all issue types if left empty.

JQL Filter

Defines a JQL condition to match the set of issues the context may be applied to. JQL Filter with a combination of Project and Issue Type selected is used to determine if the Context is applicable to an Issue being sent in an email.

Description

A description of the Context.

Order

Defines the order in which the Contexts configured with the same combination of Project and Issue Type are evaluated (see examples here).

Content and Notifications

The content of a context specifies templates and canned responses to be used when sending manual emails.

AttributeDescription

Template

Defines the default email template that Jira Email This Issue will use when emails are sent. The template selected here is not visible on the email screen's editor, it can be thought of as a frame for your emails. Read more here.

Mail Body Initializer Template

A template used for initializing the email subject and body on the email screen. Read more here.

Template Categories

Categories are groups of email templates. Once selected here, users are able to choose a template from the given category on the email screen's dropdown list. Read more here.

Notification

Defines issue event notifications for the context. They can work alongside Jira Notification Schemes, and allow you to fully customize notifications. Read more here.

Note: Either a Template or a Notification is mandatory. You cannot create "empty" contexts without at least either one of these.

Additional Settings

Additional content settings allow you to further configure options for your outgoing emails.

AttributeDescription

Field for External Watchers

A text custom field where non-Jira user email addresses will be saved if the "Add recipients to watchers" option in Manual Email Default settings is enabled. Read more here.

Sender Name Pattern

A velocity markup pattern or a static text to format a sender name in outgoing emails. E.g. if you don't want to show the name of real users as the sender of emails, you can include the project name or the value of a custom field.

Note: Not all SMTP servers allow for this setting. Please check your SMTP server options for confirmation.

From Address Pattern

Velocity markup pattern or a static email address to format the From Address in outgoing emails. E.g. if you don't want to show the name of real users as the sender of emails, you can include the project name or value of a custom field.

Note: Not all SMTP servers allow for this setting, please check your SMTP server options for confirmation.

Reply-To Address Pattern

Velocity markup pattern or a custom email address to format the Reply-to Email Address in outgoing emails. This is very useful if your IMAP and SMTP server addresses are different.

Bcc Address

A single email address, if specified, will be added as a Bcc recipient in all emails sent via this Context.

Email Details in Comments

Option to set whether comments should include the email details (such as To:, From:, Attachments in the email etc.). This option is about comments that are created from manual outgoing emails and added to the issue.

Send Individual Emails

Enable this if you want each recipient to receive a separate email instead of sending a single email to all recipients.

Learn more about this feature

SMTP Connection

Select the SMTP connection to be used to deliver emails via this Context. Default is Jira's outgoing mail setting. SINCE 7.1.1.17

Email Headers

Custom Email headers of outgoing emails may be set using this attribute. The field should contain email headers in the format of headername:headervalue, multiple headers should be entered one per line.

SINCE 8.0.6

Context Resolution Algorithm

There may be multiple contexts applicable to an issue. The best-matching context is selected for each issue to determine the email template or notification rules that apply to that issue.

Contexts are resolved from the strongest to the weakest match. Here are the steps performed:

  1. Find all Contexts that are configured with a project and an issue type, and iterate through each of them in the order of the Order attribute (see above):

    1. if the Context that is being evaluated has a JQL filter, check if the Issue matches it. If so, we stop processing and use the Context.

    2. If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.

  2. If no Context has been found in the previous step, find all Contexts that are configured with an Issue Type but not with a Project, and iterate through each of them in the order of the Order attribute (see above):

    1. if the Context that is being evaluated has a JQL filter, check if the Issue matches it. If so, we stop processing and use the Context.

    2. If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.

  3. If no Context has been found in the previous step, find all Contexts that are configured with a Project but not with an Issue Type, and iterate through each of them in the order of the Order attribute (see above):

    1. if the Context that is being evaluated has a JQL filter, check if the Issue matches it. If so, we stop processing and use the Context.

    2. If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.

  4. If no Context has been found in the previous step, find all Contexts that are not configured with an Issue Type or a Project, and iterate through each of them in the order of the Order attribute (see above):

    1. if the Context that is being evaluated has a JQL filter, check if the Issue matches it. If so, we stop processing and use the Context.

    2. If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.

  5. If no Context has been found in the previous steps, use an implicit default Context.

Examples

This is how contexts are evaluated based on how well they match an issue:

ProjectIssue typeJQL Filter

Context 1

Example Service Management Project

Bug

resolution IS EMPTY

Context 2

Example Service Management Project

Bug

priority = Blocker

Context 3

Example Service Management Project

(empty, i.e. applies to all types)

priority = Critical

Context 4

Example Service Management Project

(empty, i.e. applies to all types)

(empty)

Context 5

(empty, i.e. applies to all projects)

New Feature

(empty)

Context 6

(empty, i.e. applies to all projects)

(empty, i.e. applies to all types)

priority = Critical

Context 7

(empty, i.e. applies to all projects)

(empty, i.e. applies to all types)

(empty)

Some examples of contexts are evaluated for an issue:

Issue attributesMatching ContextExplanation
  • Project: Example Service Management Project

  • Type: Bug

  • Priority: Normal

  • Unresolved

Context 1

All attributes are directly matching the Context's settings: it's in the right project, has the correct issue type, and the resolution is empty.

  • Project: Example Service Management Project

  • Type: Bug

  • Priority: Normal

  • Resolution: Fixed

Context 4

Context 1 does not match the issue as it is resolved (resolution is NOT empty).

Context 2 does not match the issue as it is of Normal priority (not blocker).

Context 3 does not match the issue as it is of Normal priority (not critical).

Context 4 matches the issue, because the issue is in the correct project, the context is applicable to ALL issue types and there is no JQL to put any restrictions on the issue.

  • Project: Internal IT Project

  • Type: Bug

  • Priority: Critical

  • Resolution: Fixed

Context 6

Context 1-4 does not match the issue as the issue is in the Internal IT Project not the Example Service Management Project.

Context 5 does not match the issue as it is a Bug, not a New Feature.

Context 6 matches the issue as it is of Critical priority and both the project and issue type settings are empty, meaning that they are applicable to all projects and issue types.

  • Project: Internal IT Project

  • Type: Task

  • Priority: Minor

  • Resolution: Fixed

Context 7

Context 1-6 does not match the issue as it is not fulfilling the Context attributes (the issue isn't in the Example Service Management Project, it is not a new feature, its priority is not critical).

Context 7 matches the issue as the Context does not have any restrictions at all.

Enabling/disabling contexts

Contexts may be disabled and enabled again. This allows admins to test their configuration without having to remove or change contexts. Disabled contexts are disregarded in the context resolution algorithm explained above.

Last updated