Contexts
This is an old documentation
This documentation page is valid upto version 7.0.28 of Email This Issue.
For 7.1 and later versions, the documentation is in a new location.
Contexts are defined by unique combination of project and issue type pairs. Both the project and type attributes may be left empty to define a broader context.
Contexts
Context associate templates and notifications to projects and/or issue types. It is possible to add multiple Contexts with the same Project and Issue type but with different JQL filter.
Context Attributes
Attribute | Description |
---|---|
Project | defines the project on which the context is applied. May be left empty. |
Issue Type | defines the type on which the context is applied. May be left empty. |
JQL Filter | defines a JQL condition to match the set of issues the context may be applied to. JQL Filter with combination of Product and Issue Type selected, is used to determine if the Context is applicable to an Issue being sent in an email. Optional, since version 6.2. |
Order | defines the order in which the Contexts configured with the same combination of Product and Issue Type are evaluated. Since version 6.2. |
Template | defines the default email template JETI will use when emails are sent. |
Prefill template | a template used to initialize email subject and body in the email screen that opens via the Email button (since v6.0). Read more on how to use Prefill Templates. |
Template Categories | categories (groups) of templates that are made available in the email screen to choose from. Once selected, users will be able to choose a template from a dropdown list and preview the email generated using the selected template before actually sending it SINCE VERSION 6.2.1 |
Notification | defines issue event notification rules for the context. This is analogous to JIRA Notification Schemes but allows you to fully customize notifications |
External Watcher Field | text custom field where non-JIRA user email addresses will be saved if "Add recipients to watchers" options is enabled. |
Sender Name Pattern | velocity markup pattern to format sender name in outgoing emails. E.g. if you don't want to show name of real users as sender of emails, you can include the project name or value of a custom field. |
From Address | velocity markup pattern to format From Address in outgoing emails. E.g. if you don't want to show name of real users as sender of emails, you can include the project name or value of a custom field. |
Bcc Address | a single email address, if specified, the address will be added as a Bcc recipient in all emails sent via this Context. |
Canned Responses | enable or disable the use of Canned Responses in this Context. If enabled, you can select response categories to use. |
Comments | boolean attribute, comments should or should not include email details. |
Either Template or Notification is mandatory. You cannot create "empty" contexts.
Context Resolution Algorithm
There may be multiple contexts applicable for 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:
- 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):
- 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.
- If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.
- 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):
- 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.
- If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.
- If no Context has been found in the previous step, find all Contexts that are configured with an Project but not with an Issue Type, and iterate through each of them in the order of the Order attribute (see above):
- 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.
- If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.
- 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):
- 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.
- If the Context that is being evaluated does not have a JQL filter, we stop processing and use the Context.
- If no Context has been found in the previous steps, use an implicit default Context.
Some examples of Contexts:
Project | Issue type | JQL Filter | |
---|---|---|---|
1 | Project1 | Bug | resolution IS EMPTY |
2 | Project1 | Bug | priority = Blocker |
3 | Project1 | (empty, i.e. applies to all types) | priority = Critical |
4 | Project1 | (empty, i.e. applies to all types) | |
5 | (empty, i.e. applies to all projects) | New Feature | |
6 | (empty, i.e. applies to all projects) | (empty, i.e. applies to all types) | priority = Critical |
7 | (empty, i.e. applies to all projects) | (empty, i.e. applies to all types) |
Some examples of contexts are evaluated for an issue:
Issue | Matching Context | Explanation |
---|---|---|
Issue attributes:
| 1 | All attriubutes are directly matching the Context's settings |
Issue attributes:
| 4 | Context 1 is not matching the issue as it is resolved. Context 2 is not matching the issue as it is of Normal priority. Context 3 is not matching the issue as it is of Normal priority. Context 4 is matching the issue. |
Issue attributes:
| 6 | Context 1-4 is not matching the issue as it is in Project2 not Project 1. Context 5 is not matching the issue as it is a Bug not a New Feature. Context 6 is matching the issue as it is of Critical priority. |
Issue attributes:
| 7 | Context 1-6 is not matching the issue as it is not fulfilling the Context attributes. Context 7 is matching the issue as the Context does not have any restriction |
Examples of how Contexts are resolved:
- for an issue that is a Bug in project P1, the first context is selected
- for an issue that is a Bug in some other project P2, the second context is selected
- for an issue that is an Improvement (non-Bug) in project P1, the third context is selected
- for an issue that is an Improvement (non-Bug) in some other project P2, the fourth context is selected
Gallery
![]() |
![]() |
![]() |