Why does userX get duplicate notifications?

Owned by Andy Brook [Plugin People] (Unlicensed)
Nov 27, 2015
3 min read

Definitions

Non-JIRA user : a user who interacts with JIRA only by email (NOTE: yes, technically JEMH also support JIRA account holders without right to use, see next)

JIRA user: a user who has an account in JIRA regardless of status.

Sources of notifications

In a default JIRA instance, Projects are associated with a Notification Scheme, which drives notifications when events are fired in the workflow, e.g. ISSUE_CREATED.

If you are using JEMH for notification of JIRA-users project-association with the Notification Scheme should be removed as this is a cause of duplicate notifications!

JEMH Non-JIRA notifications via Event Listener

The Event Listener section allows configuration for notifications for per-Project (well, per-match, as its also CSV regular expression compatible) non-JIRA user notification (as there is no 'notification scheme'), this is separate to the JIRA user notifications.

JEMH JIRA notifications via Event Listener

The Event Listener section also allows configuration for notifications for per-Project JIRA user notifications. This might seem contrary at first, after all JIRA already has a notification scheme?  JEMH also supports users who do not have right to use, who may be notified for a subset of the events that regular JIRA users get, or for content customization purposes.  When this is done, if the original JIRA Project association with the notification scheme is not removed, that duplicate events get converted into email.  The solution is to deselect the notification scheme in the project so that JEMH is fully responsible for notifications.  NOTE: when this is done the project level 'notification helper' wont be able to function correctly as it doesn't know about JEMH.

JEMH Profile notifications for issue creation

Another source of notifications is driven from within the Profile, this was the original JEMH notification functionality, its job was to simply notify the original sender of an issue creation, to potentially just mail to non-JIRA users, to JIRA-users or to all users.  If the Profile > Notifications > Notify Users on Issue creation is set to anything other than NONE then this is another source of an issue creation notification.

  • note: Configuring this content is achieved by creating an ISSUE_CREATED Issue Event Template Set, and referring to it in Email > Templates > Issue Created Template Set.

JEMH Events

JEMH has two fields in the Notifications section:

  • On Create Custom Event

  • On Comment Custom Event

The purpose of these events is to fire a unique event in addition to any any other event that may be fired.  These values should only be set with unique event ID's, if standard issue events like '1' (issue created) or '6' (issue commented) are used, this will result in duplicate notifications.  If in doubt, leave it out!

ISSUE_CREATED v.s. CUSTOM ISSUE_CREATED

A long standing 'fug' with JEMH revolves around JEMH-280, in that JEMH creates an issue with core values, then sets related custom field values, attachments etc, in the second phase.  Originally this was fine, but now presents the problem that an ISSUE_CREATED event fires with no Non-JIRA user email address stored in custom fields, no addition watchers set, no custom fields set.  Existing JIRA workflow based on ISSUE_CREATED will just not work when JEMH creates issues.  The Configure JEMH for a Helpdesk environment from scratch guide describes how to create a CUSTOM event that is associated with a copy of the ISSUE_CREATED Template Set.  Allowing JEMH to issue creation notifications correctly.

If in the JEMH Event Listener, the ISSUE_CREATED and CUSTOM ISSUE_CREATED events are BOTH enabled, then duplication notifications to the 'reporter' will occur, as that is one of the fields set in the first pass.

JEMH-280 was addressed in 1.7.x, given there are documented workarounds, that do seem to work for most people, its not a critical issue to fix, and solving real world usage scenarios through features is still prioritised.

In a nutshell

If the JEMH Profile is used to notify users, there will be a value set in the Profile > Notifications > Notify Users on Issue creation, e.g. ALL.

If the JEMH Event Listener is used, there will be a Project entry in the Event Listener, whether or not an event triggers a notification is down to enabled events and the email user / JIRA user nature of the recipient involved.  JEMH will inject a summary of its configuration specific to a given project in the JIRA Project Admin > Notification section, underneath the internal JIRA notification scheme details.

If the JEMH Workflow Postfunction is used, there will be a post-function configuration listed in the workflow transition that you just performed to trigger the notification.