Auditing (legacy documentation)

What JEMHC audits

JEMHC provides audit capability for all areas of message handling, from Events generated by Jira, incoming mail processing and notifications sent.

Events from Jira

In the screenshot below you can see that events from Jira get queued for processing, after ~1min, the events are handled, with the notification transport used indicated on the event (eg # = slack).

Events are captured and can be used to do live preview of notification template customization.

 

Event Report

When an message comes in and has a problem, you can view the report by clicking on the ‘View Report’ icon on the right of the record.

 

 

This will display a report similar to the following.  The report will show where the problem was.  Once the particular problems have been addressed you can click on Re-Run to process the message again.  This will allow you to ensure that the problems have been addressed.

Failed Event Report

When webhook events fail to be processed, they are retried. Once all retry attempts have been used, the event goes into ERROR state. These messages are displayed in the ‘Failed Events’ auditing tab.

Currently, failed events are also retained for the same duration. We are aware that this leaves insufficient time to retry failed events. (https://thepluginpeople.atlassian.net/browse/JEMHC-2764 addresses this issue).

 

Because Failed Events have exhausted all retry attempts, it is not possible to keep attempting to process the event automatically. To manually re-run these events, go to JEMHCloud > Auditing > Failed Events.

 

Event Statuses

For each audit report there is a status which defines the outcome of processing that event. Below are the status that are currently used within the Events auditing page.

Status

Description

Status

Description

Queuing

The Event is currently queued as it is waiting for the next minute interval. This so that other events created within the interval can be merged into one notification.

Processing

The Event data is currently being processed by JEMHC.

Success

The event was processed correctly and resulted in a notification being sent to a recipient.

Ignored

Audit event did not send a notification as there was either no recipients or the template did not render any content within the notification.

Typically caused by not using $jemhUtils.setFieldRendered() within the macro/template. See the Macro documentation for more info about $jemhUtils.setFieldRendered(): https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/1031340058

Incoming mail

Here we show outcome of all mail received. If its not listed, JEMHC never got the mail (in full). For a limited time the mail is available here for review, and can be re-executed or converted in to a JEMHC Test Case for further testing.

Retention of inbound/outbound mail is for diagnostic purposes, we currently have a rolling limit of 100 notifications. Retention can be opted-out, re-enabling requires contacting support@thepluginpeople.com

Maintenance traffic

The Inbound Messages auditing page allows you to find traffic that is maintenance, that represent messages that did not create or update an issue. Typically, such messages are (a) not addresses to a recipient that your Profile has set as a catchemail (mailbox) address. We know this can also be due to manually using the mailbox account and sending mail (tell tale sign is that the mail in is from your inbound mailbox address).

Locate maintenance traffic by filtering on Usage : Maintenance In

You should locate the source of maintenance traffic and remove as it will consume your Plan for no real benefit. Left unchecked, high levels of maintenance can consume all your monthly capacity, and result in service interruption until more is purchased!

Inbound Mail Statuses

For each incoming message there will be a Operation status which defines the outcome of processing that message. Below are the statuses that are currently used within the Incoming Messages auditing page.

Status

Description

Status

Description

Created

This means that there was no errors with the processing of the email and it resulted in a new issue being created.

Updated

This means that there was no errors with the processing of the email and it resulted in a new comment being added to the relevant issue.

No CatchEmail match

This means that none of the Profile’s Catch Email address could be found within the email. This results in a forward email being sent or this email being dropped and not processed.

Error Processing

This means that there was an error while processing the email. For example the sender is not already involved on the issue. The details about the error will be found within the processing report for the email.

Message Dropped

This occurs when there is a outcome of Dropped whilst processing the email. For example, the email does not related to an existing issue and the profile is configured to only comment on issues.

Directive Set Link

This occurs when the email is sent when a Directive Set Link has been triggered. See the following page for more info about Directive Sets: https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/122748975

No Change

This occurs when an email relates to an existing issue but it does not result in any values being changed and no comment being added.

Excluded

When the email contains a sender, recipient or a Subject that the Profile is configured to exclude.

Precedence Bulk

When the email contains a Precedence Bulk header and the Profile is configured to Drop/Format these emails.

Limit Exceeded

This occurs when:

  • The email content has too many characters

  • The commenting issue has exceeded the configured Profile comment count.

Outbound mail

Mail sent is tracked, the mail, in full, is available through JEMHC for a short time.

Retention of inbound/outbound mail is for diagnostic purposes, we currently have a rolling limit of 100 notifications. Retention can be opted-out, re-enabling requires contacting support@thepluginpeople.com

Outbound mail Statuses

For each outbound notification that is sent there is a Notification type and this defines the type of notification that was sent. Below are the current Notification types that are used.

Status

Description

Status

Description

Notification sent (Email Icon)

This defines that a notification has been sent to at-least one of the recipients on the issue.

Rejected

Reject Notifications are sent when the Profile has rejected an incoming message from being processed.

Forwarded

Forward notifications are sent when the incoming email has resulted in a forward outcome.

Ping

Ping notifications are used to test whether JEMHC is able to send notifications using the configured Outbound Mail server.