Get field values of transition screen in comment template?

[Charlie Misonne]

Hi Community!

I need predifiend comment for the JSM agents to use. Several solutions already exists: out of the box canned responses, canned responses pro (Appfire), comment templates (part of scriptrunner)

I also need to use custom fields in the comments which is not possile with the default canned responses.

Here is the difficlult part: when the agent changes the value of a custom field on a transition screen the comment template should use that new value and not the value that is currently saved on the issue.
It does not seem possible with Appfire's solution (confirmed by vendor).

In the example below I want the new value of unavailability type in the comment.

I know the value is not stored in the issue until the transition has been executed. But is their a way to access the transition field values with the groovy code?

This scriptrunner code gets the current value on the issue (not the transition screen value)

def cfUnavailability = customFieldManager.getCustomFieldObjectsByName("Unavailability Type")[0]

config.unavailabilityType = issue.getCustomFieldValue(cfUnavailability)

return true

${config.unavailabilityType}

Any ideas?

[Peter-Dave Sheehan]

Hi Charlie

I pondered your use case a bit and came up with the following... 

1) From a script runner post function, you can read the comment supplied by the user (or a template tool) using the transentVars variable in the binding.

2) Using groovy GStringTemplateEngine, you can interpret code in ${} in the comment.

Put together in a simple example script:

package com.qad.its.jira.workflow.postfunction

import groovy.text.GStringTemplateEngine

def engine = new GStringTemplateEngine()
def currentComment = transientVars.comment
log.info "CurrentCOmment=$currentComment"
if(currentComment) {
    //run the currentComment through a GStringTemplateEngine to interpret ${}
    def newComment = engine.createTemplate(currentComment).make(transientVars)
    log.info "NewCOmment: $newComment"
    transientVars.comment = newComment.toString()
}

Then if you configure your template, to automatically include:

This is the text part of the template/canned response 
Unavailability Type= ${issue.getCustomFieldValue('Unavailability Type').value}
More from the template.

There are definitely some security risks in allowing any code to be interpreted like this by anyone posting a transition. 

For example, I can include ${issue.addComment('comment within a comment')} in my comment and this will generate another comment

So maybe you prefer to hard-code the replacement. Or limit the kind of substitutions that are allowed.

But now, you should have the tools to read an existing comment and overwrite it as necessary.