Ensure that attachments added whilst adding a long comment are sent
The Jira problem
Attachments when created have no relation to the comment through which they (may) have been made. This makes it difficult for add-ons reacting to Issue Events (like JEMH) to do sensible things. For all intents and purposes, when an attachment is created, an ISSUE_UPDATED event fires, with no comment. When attachments are created they are created with a time-stamp in the system time zone at the point the user uploaded them (not at the point the final comment is made) which results in a spread of attachment creation times.
Historically JEMH used time-correlation to locate attachments, which worked well for JEMH driven issue creation and commenting. The one scenario that did not work well was when users added attachments, and took some time (many minutes) to get to the point of submitting a comment. This 'broke' the approach, and caused some attachments added 'early' to be missed. Clearly, this was not good enough.
https://jira.atlassian.com/browse/JRA-34927 : Automatically include attachment link in attachment comment (if comment submitted also updated attachments that were added during that process, all this would go away)
https://jira.atlassian.com/browse/JRA-43448 : When attachments are uploaded as part of a transition they get the upload time-stamp as their creation date (this would allow correlation by a common time-stamp)
The JEMH solution
From version 1.8.10, JEMH uses Entity Properties to tag attachments when they have been sent, as a way to stop re-broadcasting of the same files by subsequent events.
This enables JEMH to be configured as follows in the JEMH Event Listener Project Mapping (see Use Project Mappings)
Below is an example Project Mapping:
1) Require comments in order to notify
By enabling this check-box, JEMH will not notify users unless there is a comment present. This means that:
when attachments are added, it will not generate a notification, so the attachment will still be 'untagged'
however, when individual issue updates such as a priority change will not result in notification
2) Include Attachments in Notifications
By enabling attachments to be included, any attachments that have not been already tagged by JEMH will be attached (to TEXT emails and HTML emails).
3) In-line Images
By enabling in-line images, those images pasted into emails, and/or pasted into a comment during comment-entry (resulting in wiki mark-up within the comment) will be rendered in outgoing notifications the same way. This feature respects rendered thumbnail and full size descriptions within the mark-up.
4) Notification Format
By selecting the HTML format, in-line images can be embedded in the notification body. If TEXT is selected, in-line images cannot be embedded and only wiki mark-up will be shown.
Standard scenario example
Steps
An interactive user:
starts adding a comment
adds some attachments
has a coffee
reviews the comment
submits the comment
Outcome
Notifications to JIRA and Non-JIRA users occur. All attachments 'added' during commenting will be 'added' to outbound notifications, all images that were referred as full-size images will be included full-size, all images referred as thumbnails will be included as thumbnails.
Subsequent comments will not include any of the attachments already sent.
Concurrent commenting scenario example
Steps
An interactive user:
starts adding a comment
adds some attachments
has a coffee
another user adds a quick comment, and submits
Outcome (from second commenter)
Notifications to JIRA and Non-JIRA users occur. All attachments not yet tagged are included - the attachments added by the first commenter are now 'stolen' by the new commenter (See Problem Statement, there is no relationship between Attachments and comments within JIRA). All sent attachments are tagged as being sent through the Event Listener.
The interactive user continues:
5. reviews the comment
6. submits the comment
Outcome (from initial commenter)
Notifications to JIRA and Non-JIRA users occur. All attachments not yet tagged are included (there are none, they are all tagged). However, JEMH will include referred images (in-line wiki mark-up referrals to existing images are treated separately).
The bottom line
If users upload images and use wiki mark-up to embed them in comments, JEMH will always do the right thing. Only when other documents are attached will the problem scenario occur.