I found myself in a situation wherein a ProForma form on the Jira Service Desk contained a custom field. I needed the contents of that field to dictate which team the resulting issue was assigned to.
The first thing I tried was to add a Groovy script to a transition in the Service Desk Workflow. If I could tell the script to transition the issue based on the value of a field, the issue should be resolved.
This turned out to not be possible. For some reason, the value of a custom field is not populated from the form to the field until after the ticket “lands”, or finishes moving through the workflow. It’s not enough to simply trigger the script after the Open/Create transition. No matter what, the value of the custom field is not available until after all of the initial transitions have finished. No matter how you try to reference the custom field, the value returned will always be NULL.
This was extremely aggravating, especially when it seems like such a simple solution SHOULD work, and it’s not clear whether the issue lies with your script or with the system.
The solution you’re going to come across most often is to add a sleep() timer to your code. This does not solve the issue.
In the end, I came up with two solutions. One of them was pretty ugly, and the other was a lot cleaner.
The first was to simply run a scheduled job that looked for tickets matching certain criteria, and have that update the ticket in the ways that I needed. This is less than ideal; it presents a pretty heavy load on the system, and runs mindlessly.
The better solution was to set up a listener, to watch for ticket updates in the Service Desk project. Rather that running constantly, listeners listen for specific events or actions happening in the system. This makes it a much more selective process; not only does it not run constantly, but it only happens when certain events or triggers occur.
Setting up a listener presented its own unique challenges, but in the end it was the solution that I was looking for. One example of a challenge is that for some reason, I couldn’t get it to update the summary of the ticket. Rather, I could get it to update the summary, but it would then refuse to process the rest of the script.
This frustrated me to no end, because it was such a simple thing that wasn’t working. It worked just fine in the ScriptRunner script console. Something about the listener was different.
As a workaround, I added a summary update to a Fast Track postfunction. This worked, but I didn’t want to leave it at that.
This morning I realized that I was missing the forest for the trees. I already had the functionality in place to add Issue Update Parameters during issue transitions. I simply needed to include an additional parameter. So it went from this:
def issueInputParameters = issueService.newIssueInputParameters()
issueInputParameters.addCustomFieldValue(12210, "13702")
def transitionValidationResult = issueService.validateTransition(user, issue.id, actionId, issueInputParameters,transitionOptions)
if (transitionValidationResult.isValid()) {
def transitionResult = issueService.transition(user, transitionValidationResult)
To this:
def issueInputParameters = issueService.newIssueInputParameters()
issueInputParameters.addCustomFieldValue(12210, "13702")
issueInputParameters.setSummary("New Summary")
def transitionValidationResult = issueService.validateTransition(user, issue.id, actionId, issueInputParameters,transitionOptions)
if (transitionValidationResult.isValid()) {
def transitionResult = issueService.transition(user, transitionValidationResult)In order to fix the issue, I needed to walk away from it. It’s so easy to get tunnel vision, and to get stuck on a certain solution or idea that you’re certain is going to work eventually.
Sometimes taking a break is the most productive thing you can do for yourself.