Enable the Notification History Issue Tab
- Andy Brook [Plugin People] (Unlicensed)
- Ryan Clifton
Background
The Notification History tab is a convenient way to view the notification history for an issue. JEMH must be used as the primary notification route (Event Listener) as only its notifications will be logged (therefore the JIRA project should not have a notification scheme selected).
This tutorial follows on from Enable non-Jira Account holders to receive issue updates and create/comment on Issues.
Configuration checks
Target Project notification scheme
The target project has no Notification Scheme selected (stops JIRA executing notifications)
JEMH's Event Listener is enabled
Create a JEMH Event Listener configuration for the target project
See Use Event Listener for Issue Events for more information on its configuration.
Non-JIRA and JIRA notifications
Non-JIRA users are dealt with entirely separately from JIRA user notifications. This allows a single project to have one configuration for remote participants based on events, as well as the usual JIRA user notification based on Notification Scheme.
Configuring the Non-JIRA user notification
Project Key | The target project key |
|---|---|
Notification Format | Text or HTML, you decide |
Assert Security | If set, any comments marked with a Security Level will NOT be broadcast (default) |
Store Notification History | Required to enable collection of data that feeds the Notification History issue tab |
CSV email Custom Field | The custom field used in the project to store non-JIRA user email addresses, as per JEMH Profile |
Events | Enable those events that you want a remote user to get notifications for. By default NO notifications will be sent, select Templates that are used for the notifications. If no IssueEvent TemplateSets have been created, only the DEFAULT will be available. |
Here is an example configuration before saving:
After saving:
Configuring the JIRA user notification
Define the notification scheme
By default, no notification scheme as been set. As this replaces the JIRA project notifications a suitable Notification Scheme must be selected in order for JIRA users to receive notifications.
Shared configuration
When a Event Listener Project Configuration is created, some values are shared between JIRA and non-JIRA notifications, e.g. the definition of the Project and Notification History storage, changes to one will affect the other.
Edit the JIRA notification configuration by clicking on the pen icon, and select a notification scheme, as well as the events required to be notified:
After saving the JIRA notification configuration you will see:
At this point, the JEMH Event Listener is fully primed to issue notifications to non-JIRA and JIRA users and to collect the notification traffic that is needed for the Notification History, all that remains is to create some traffic.
Test Case
Starting with a JEMH Test Case (see Create a Test Case), just run an example to create an issue, set with whatever inbound address is required for your Profile.
After running the Test Case the results should be successful, e.g.:
Note in the created issue, the new Notification History Issue Tab:
Opening the Notification History tab will show the conversation of the issue (which will be blank as the issue was just created):
Adding a comment to the issue through the UI:
Results in:
Now, going back to the Test Case, imagine the remote user received that notification and replies, this can be mocked by using the same JEMH Test Case as earlier, just add the created issue KEY to the subject of the email before sending.
What just happened? The screenshot above shows the remote user commenting on the issue, in context. Notice the hourglass, hover over it, it will tell you how long the remote user took to reply to the previous comment by 'admin'.
Notice the issue event displayed below the user admin? This is JIRA sending out notifications to whoever is applicable, in this case 'admin' doesn't get notified of their own changes, so the only person left is the remote user. If there were other non-JIRA users on the issue, they would also be listed.
Editing and repeating the Test Case, this time the remote user adds in a new non-JIRA user to the conversation (JEMH security works by only allowing users with addresses already listed to add more).
Detailed comment-header
If the JEMH Profile > Email > Templates > Comment Header TemplateSet refers to a DETAILED Comment Header Template Set (see below).
Creating a detailed comment header Template Set
Go to JEMH > Template Sets > Templates > Comment Header and press the Plus icon(+).
After enabling the DETAILED comment header, the conversational history becomes a record of who was brought into the conversation by whom:
Note the list of notified non-JIRA recipients:
Eh? This is like the comment view?
Well so far yes. Now, going and editing several Issue Fields (e.g. priority, add an attachment, change issue type, change assignee), all those issue updated events will be isolated to history (or the Events Tab at the bottom of the Notification History tab:
Events relating to update can be seen to NOT result in a notification:
Considerations for busy sites
Enable tracking wholesale for large numbers of projects is going to eat database storage. The intention is that it is used for key user-facing projects.