JQL restAPI frequently returns null values

[Wesley Stewart]

I am running a fairly simple JQL, counting to results and returning them in a JSON format:

It works for a few days, and then it stops and I get this:

[{"target":"jira Open Tickets","datapoints":[[0]]},{"target":"jira Open Procurement","datapoints":[[0]]}]

I simply disabled and re-enable and boom!

[{"target":"jira Open Tickets","datapoints":[[16]]},{"target":"jira Open Procurement","datapoints":[[10]]}]

So it's strange it seems happy and it works and then later returns null.  I was curious if anyone could see any issues.  I am very very new to Java.

import com.onresolve.scriptrunner.runner.rest.common.CustomEndpointDelegate
import groovy.json.JsonBuilder
import groovy.transform.BaseScript

import javax.ws.rs.core.MultivaluedMap
import javax.ws.rs.core.Response

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.search.SearchProvider
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.web.bean.PagerFilter

@BaseScript CustomEndpointDelegate delegate

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.jql.parser.JqlQueryParser

def jql= "project = PROJ and resolution = Unresolved ORDER BY 'Time to resolution' ASC"
def jqlProcurement = "project = PROJ AND status = 'Awaiting Delivery'"


def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def jqlQueryParser = ComponentAccessor.getComponent(JqlQueryParser)
def searchService = ComponentAccessor.getComponent(SearchService)

def query = jqlQueryParser.parseQuery(jql)
def queryProcurement = jqlQueryParser.parseQuery(jqlProcurement)

long[] results
results = new long[1]
results[0] = searchService.searchCount(user,query)

long[] resultsProcurement
resultsProcurement = new long[1]
resultsProcurement[0] = searchService.searchCount(user,queryProcurement)

helpdeskOpen(httpMethod: "GET") { MultivaluedMap queryParams, String body ->
return Response.ok(new JsonBuilder([
["target": "jira Open Tickets","datapoints": [results]],
["target": "jira Open Procurement","datapoints": [resultsProcurement]]
]).toString()).build();
}

 

[Вячеслав Рыжов]

Having same issue :(

@Kamran Ansari - have you found how to fix it?

Thank you

[Kamran Ansari]

@Viacheslav Unfortunately, no.

I wish Adaptavist customer support was as good as their product, but unfortunately, this issue failed to get any traction from them. In the end, I had to implement a workaround which involved creating a string version of this scripted field using a Groovy script. So basically, we have two versions of the same field now:

1. Using Date of First Transition that is "JQL Date Time functions" friendly but NOT Confluence friendly

2. Using a custom scripted field that is Confluence friendly, but won't work with JQL.

Unfortunately, I won't be able to share the Groovy script with you, but you should be able to find plenty of examples online on how to walk the Jira issue change history to get to the bit of information that your Groovy script needs to return. The key is, you need to return the date/time string.

Hope that helps. If you do come across a better solution, I'd appreciate if you could post about it here, so others in the same boat could benefit.

Good luck!

[Вячеслав Рыжов]

Ok. Thank you for answer.

In my case - i have a field wich show version start date for issue

Template - date

here is a code

import org.slf4j.Logger
import org.slf4j.LoggerFactory
import java.sql.Timestamp
import com.atlassian.jira.project.version.Version

Logger log = LoggerFactory.getLogger("Release Version")
log.info("Release Version started")

Version version = issue.getFixVersions()[0]
log.debug("Version: ${version}")
Timestamp result = (version)? version.getReleaseDate() : null
log.debug("Resuilt: ${result}")
log.info("Release Version ended")
return result

But in Confluence it shows 

 $xmlutils.escapeForCdata($value.toString())

So i create second field special for confluence jira issue macros

Template - text field

import org.slf4j.Logger
import org.slf4j.LoggerFactory
import java.sql.Timestamp
import com.atlassian.jira.project.version.Version

Logger log = LoggerFactory.getLogger("Release Version")
log.info("Release Version started")

Version version = issue.getFixVersions()[0]
log.debug("Version: ${version}")
String result = (version)? version.getReleaseDate() : null
log.debug("Resuilt: ${result}")
log.info("Release Version ended")

def format1 = result
def format2 = Date.parse("yyyy-MM-dd hh:mm:ss", format1).format("dd.MM.yyyy")

return format2

[Nic Brough -Adaptavist-]

For what it's worth, it's not a problem with Scriptrunner, it's the way Jira serves up field data to Confluence.  That's why you got no traction with SR support - there's nothing they can do to fix it.

[Nic Brough -Adaptavist-]

I think you might have to fix this by changing the output of the scripted field.

I think you have selected a type of field which has formatting that relies on Jira's UI code to be rendered usefully for the users hitting the web interface, but Confluence does not know that this data needs to be rendered, it displays the physical data being returned.

So, you would either need to get Confluence to understand that it needs to do some rendering, or you have to simplify the output so that it does not need to be rendered and can be drawn out raw.

[Kamran Ansari]

Hello Nic,

Thanks for the quick turnaround on this!

To your point about fixing this by changing the output of the scripted field and simplfying it:

I don't know if that's possible, given that I'm using one of ScriptRunner's canned field called Date of First Transition, and I haven't been able to find a way to change its output via the field configuration dialog (the only way to interact with this field). All it lets me do is specify a Field Name, Field Description, Field Note, Issue Status, and Preview Issue Key. The Groovy code that the field is bound to is to be found nowhere.

More importantly though, the return data-type of the field is Date/time which both ScriptRunner and Confluence should be well equipped to handle, and I feel that changing it to a simpler type (such as string) would come with other undesirable effects (JQL date/time functions and comparison operators would probably no longer work, for example).

Thoughts?

Thanks!