Month: May 2022

Overview

I found myself with an interesting Jira problem today.  We had a dashboard that wasn’t showing all issues relevant to the JQL query in the filter.   The issues were fully present in the system, but would only appear if we went in after creation and tweaked them in some way.
Essentially we had issues that weren’t being picked up by the filter because the system didn’t see them as “complete”.

Here’s the sanitized JQL:

 project = <project> AND status = Queued AND "<Custom Field>" = "<value>" 

It was picking up some of the issues, remember. And the issues were all created in the same way: they came in through the Service Desk as Service Requests. So the JQL wasn’t the issue.

Trying Different Solutions

I already had a listener running as part of the process, so I tried adding an issueUpdate statement to it:

 issueManager.updateIssue(user, issue, EventDispatchOption.ISSUE_UPDATED, false) 

This did not resolve the issue.   I next tried updating the issue summary to be itself as part of the Workflow Transition process:

 issue.setSummary(issue.summary + " - " + issue.reporter.displayName) 

This also did not resolve the issue.

Resolving the Issue

In the end I solved the issue by introducing a re-index

Introduction

Once upon a time I spent a week writing a script to automate some functionality for Jira.  The script was supposed to assign issues based on certain criteria, and also update a custom field that contained the name of the team that was currently responsible for the ticket.

At the end of the week I had the script working according to the specifications.   We tested it on Friday afternoon, and all was well.
On Monday morning the project manager sent me an email, notifying me that the script now had to work a completely different way.  It also had to be finished by the end of that day, as Tuesday was the day they were using the script as part of a training session.

Updating the Script

The good news was that for the most part, the changes I had to make to the script were reductive. It had to do fewer things.   However, I had initially included the Custom Field update as part of the transition:

    def issueInputParameters = issueService.newIssueInputParameters()
    issueInputParameters.addCustomFieldValue(customFieldID, customFieldValue)
    //The request is for a new workstation, so set Next to Act to Tier 1 - IDIR Services
    issueInputParameters.setSummary(issue.summary + " - " + issue.getReporterUser().displayName)
    //Set 

 

During the process of writing a listener for Jira, I found myself encountering a strange error.  The error looked like this:

com.atlassian.servicedesk.api.AuthorizationException: The action performed required a logged in user. Please log in and try again.

This was strange for two reasons. First, I am a Jira administrator with total access to the entire instance. Second, my script had explicitly supplied the logged-in user (myself) as the account under which to run the script.

What gives?

The code I used to supply my own account to the script looks like so:

 def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
 

This solution had been more than sufficient previously.   I searched and I searched and I couldn’t find anything related to my issue.  If you search the text of the error, three results are returned, and they’re about REST API permissions. Not applicable here.

In the end I accidentally stumbled on the answer, by trying different solutions for the action I was trying to take.  What I was trying to do was get the Request Type of the issue in question.

The solution was to explicitly provide an account to the script, under which the method could run.   That is, I changed the code to:

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

Introduction

Jira Issues can only be transition between states in a manner that resembles the Workflow of the parent project. In other words, before you begin trying to script the transition of a Jira issue, you must understand the workflow and what the available transitions actually are.

Further to that point, there’s more to transitions that simply changing the status of an issue. Some transitions have criteria.  For example, you may want to move an issue from Open to Pending.  In order to do so, you may need to select a Pending State, and add a comment.  How do you account for that in a script?

Using Groovy and ScriptRunner to transition Jira issues is a pretty straightforward process. So too is this process quite simple if you need to include transition criteria.  It’s simple, if you can find a guide on how to do it. As with most of the things I blog about, I couldn’t find instructions for accomplishing this simple task, so I’m writing my own.

Overview

The script we’re going to explore transitions a Jira issue from one state to another, and fills in the criteria required to make the transition a valid one.  As