JEMH: Merging issues when users forget to add key

[Mark S. Rasmussen]

We have a typical workflow that goes like this:

• Users send emails that are picked up by JEMH and creates an issue
• Users are sent an email confirming the creation, including the key
• If users reply to this mail, the key is automatically part of the subject and all is good

However, let's say a user creates issue HELP-1234 and replies back and forth a couple of times. Now the user receives a mail from somebody else and wants to forward it to us - without manually adding HELP-1234 to the subject.

This results in a new issue being created by JEMH, even though this should've been part of HELP-1234.

Right now we solve this by closing the new issue and asking the user to resend the email with the correct key in the subject. However, this is manual work for us and it's cumbersome for the users.

Ideally we'd like to be able to merge/convert just the description & attachments of the new issue into a comment on the original issue.

Is there any way we can do that?

[Henning Tietgens · Accepted solution]

You could do the following.

1. Install free Script Runner plugin.
2. Create new custom field "Destination Issue" (text field)
3. Create screen "Merge Issue" with this new field
4. Add workflow transition "Merge" from Open to Closed in your workflow
5. Add "Merge Issue" as transition screen.
6. Add validator, that "Destination Issue" is required.
7. Add postfunction to set a appropiate resolution.
8. Add scripted postfunction with the following script.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.attachment.CreateAttachmentParamsBean
import com.atlassian.jira.issue.comments.CommentManager
import com.atlassian.jira.user.ApplicationUsers
import com.atlassian.jira.util.PathUtils
import eventim.JiraTools as ejt

/**
 * Create as reporter a comment on the destination issue from the description and copy the attachments
 */

CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager()
CommentManager commentManager = ComponentAccessor.getCommentManager()
IssueManager issueManager = ComponentAccessor.getIssueManager()
cfMergeIssueKey = customFieldManager.getCustomFieldObjectByName('Destination Issue')                                    

if (cfMergeIssueKey) {
    String destIssueKey = issue.getCustomFieldValue(cfMergeIssueKey)                                                    
    def destIssue = issueManager.getIssueObject(destIssueKey)                                                           
    if (destIssue) {
        commentManager.create(destIssue,ApplicationUsers.from(issue.reporter),issue.description,true)                   
        copyAttachments(issue,destIssue)                                                                                
    }
}

protected def copyAttachments(Issue issue, MutableIssue newIssue) {
    def attachmentManager = ComponentAccessor.getAttachmentManager()
    def pathManager = ComponentAccessor.getAttachmentPathManager()
    attachmentManager.getAttachments(issue).each {attachment ->
        def filePath = PathUtils.joinPaths(pathManager.attachmentPath, issue.projectObject.key, issue.key, attachment.id.toString())
        def atFile = new File(filePath)
        if (atFile.exists()) {
            try {
                if (atFile.canRead()) {
                    attachmentManager.createAttachment((new CreateAttachmentParamsBean.Builder(
                            atFile, attachment.filename, attachment.mimetype, attachment.authorObject, newIssue))
                            .createdTime(attachment.created)
                            .copySourceFile(true).build())
                }
            }
            catch (SecurityException se) {
                log.warn("Could not read attachment file. Not copying. (${se.message})")
            }
        }
        else {
            log.warn("Attachment file does not exist where it should. Not copying.")
        }
    }
}

This will add the description of the current issue as a comment to the issue with the issue key entered into the field "Destination Issue". Additionally all attachments are copied to the destination issue.

[Mark S. Rasmussen]

Hi Henning,

That looks very interesting - I'll give it a try and report back. Thanks!

Cheers,
Mark

[Özerk Dolanbay]

Hi Henning,

I just use your copyAttachments function but I couldnt pass first condition (atFile.exists()). I added these lines into else block:

log.warn(pathManager.getAttachmentPath())
log.warn(issue.getProjectObject().getKey())
log.warn(issue.getKey())
log.warn(attachment.getId().toString())

In log, there is nothing wrong with the parameters but I dont understand why it still says "Attachment file does not exist where it should. Not copying."

Any suggestions?

[Henning Tietgens]

Could you log filePath and take a look if the referenced file exists on the server?

[Henning Tietgens]

And maybe you could add a

log.warn AttachmentUtils.getAttachmentFile(attachment).absolutePath

to see the path of the attachment file object. (deprecated use)

[Özerk Dolanbay]

Our jira version is 6.1.5 and it says AttachmentUtils class is deprecated since 6.1. So, do you think that it works? I add this line to get path of the attachment:

log.warn(filePath)

[Henning Tietgens]

Deprecated doesn't mean it doesn't work, only that maybe in the next version it doesn't work anymore.

It's only for debugging purposes, to compare both path outputs.

[Özerk Dolanbay]

I edited project key so it can't find the attachment. Even if I upload a new attachment jira still stores it under the ex-file because it didnt create a new folder with the new name when I change the project key.

[Henning Tietgens]

Uh, ok, didn't know that this is possible. "Editing a Project Key" is only available in the latest JIRA documentation. In this case the AttachmentUtils way should work (until it's removed from the API). Or you can use https://docs.atlassian.com/software/jira/docs/api/latest/com/atlassian/sal/jira/project/JiraProjectManager.html#getAllProjectKeys%28%29to get all possible keys and try each one if the original project key doesn't work.

[Özerk Dolanbay]

I renamed the project directory under the attachment directory but it doesnt make sense becasue jira creates directories for new issues with ex-project key. It should be better I revert the project key.

[Andy Brook [Plugin People]]

Hi Mark,

Using the issue key in the subject is the simplest way to route a comment to an issue, other solutions exist but are more complex. You need to identity the issue somehow? What is the objection to using issue keys?

There are some options;

One 'way' is to use JEMH Directives, a user supplied way to 'point' the issue to be used, the forwarding user could then use:

@issueKey=ABC-123

Not much different than adding the issue in the subject? Added complications are in content stripping 'replies'. There is a special 'trick' to defeat the normal content stripping:

@stripComments=false

The bottom line is that JEMH needs to know what issue a mail needs to be associated with, your users know that information, they need to provide it.

If I'm missing something please clarify how you would expect an association to occur?

If you are really just looking at this scenario after the fact, you want to merge the issue, JEMH doesnt currently bundle that feature, there is a third party plugin for merging, but its not currently compatible with >5.2.11 , its a GPL licensed addon.

[Mark S. Rasmussen]

Hi Andy,

Sorry if I wan't beeing totally clear on what I want.

I have no problem using issue keys and I fully realize they're needed. The problem is that we may have a series of external (internal to our organization, but non-Jira & non-developers/technical) users that aren't disciplined enough to remember adding the issue key. They may have created an issue a week ago, forgotten all about it, receive a new mail from a customer and then just forwarding it without finding the original issue key.

I can keep trying to train our users to remember adding the key, but I know it's a loosing battle in the long run, and so I'm looking for an easy workaround where we can manually merge the issues when our "external" users forget to add the key.

Given this, adding directives isn't an option as I'd never be able to teach our users what a directive is, and even less, remember to add the directive :)

Thanks,
Mark