ScriptRunner Date of First Transition prevents issue creation

[Taylor Huston]

I am trying to get the date of when an issue first enters In Progres. Pretty standard stuff. Using the base example code from Adaptavist:

package com.onresolve.jira.groovy.test.scriptfields.scripts

import com.atlassian.jira.component.ComponentAccessor

def changeHistoryManager = ComponentAccessor.getChangeHistoryManager()
def created = changeHistoryManager.getChangeItemsForField(issue, "status").find {
it.toString == "In Progress" 
}?.getCreated()

def createdTime = created?.getTime()

createdTime ? new Date(createdTime) : null

The problem is that once I put in that code AND set the Searcher to Date Time Range picker, no one can create any issues in Jira. Specifically, they get this error when creating any Issue Type in any Project:

"We can't create this issue for you right now, it could be due to unsupported content you've entered into one or more of the issue fields. If this situation persists, contact your administrator as they'll be able to access more specific information in the log file."

Log analyzer gives some errors of "Troubleshoot a reindex failure in Jira server" but nothing I could see in that link seemed to apply.

If I create the Scripted Field and set the Template as Date Time it seems to return fine using the Preview function of ScriptRunner (it returns something like 24/Sep/18 2:39 PM), but on the actual issue view, it just gives me an 'Invalid date' error.

If I create the Scripted field and leave the Template as Text Field (multi-line) it returns the correct date, though in a different format (Mon Sep 24 18:39:03 UTC 2018), which is not ideal, but should work in the meantime.

So why when I do it the "correct" way, with the Date Time Picker Template and Date Time Range picker Searcher, does it break Jira?

Note I have NOT tried a full reindex. That takes about an hour on our instance and I haven't been able to schedule that kind of an outage window yet.

Jira Data Center v8.2.5
ScriptRunner v5.6.1.1-jira8

[PD Sheehan]

You could try to increase logging level for the indexer. But from your explanation, it seems that your script giving the indexer data in a format that it doesn't know how to handle based on the searcher.

Specifically when the issue is being created and the changeHistoryManager doesn't return any values.

I'd recommend not relying on the Log Analyser. Instead, output your own log and review/tail the log as you reproduce the issue. Or look in the logs available in the script runner execution history (visible from the script fields page).

Something like this:

import com.atlassian.jira.component.ComponentAccessor

def changeHistoryManager = ComponentAccessor.getChangeHistoryManager()
def created = changeHistoryManager.getChangeItemsForField(issue, "status").find {
    it.toString == "In Progress" 
}?.getCreated()

log.info "In progress scripted field for $issue.key: created=$created (${created.getClass()})"
def createdTime = created?.getTime()
log.info "In progress scripted field for $issue.key: createdTime=$createdTime (${createdTime.getClass()})"
def returnValue = createdTime ? new Date(createdTime) : null
log.info "In progress scripted field for $issue.key: returnValue =$returnValue (${returnValue .getClass()})"
returnValue

 When I do this in my environment, I get the following logs:

2020-01-25 15:49:20,138 INFO [runner.AbstractScriptRunner]: In progress scripted field for JSP-4482: created=2019-11-05 13:43:25.0 (class java.sql.Timestamp) 2020-01-25 15:49:20,138 INFO [runner.AbstractScriptRunner]: In progress scripted field for JSP-4482: createdTime=1572990205000 (class java.lang.Long) 2020-01-25 15:49:20,138 INFO [runner.AbstractScriptRunner]: In progress scripted field for JSP-4482: returnValue =Tue Nov 05 13:43:25 PST 2019 (class java.util.Date)

What I've found, at least with my version of Jira, is that jira prefers java.sql.Timestamp for date fields rather than java.util.Date. 

Try it like this (simpler script too):

import com.atlassian.jira.component.ComponentAccessor

def chm= ComponentAccessor.changeHistoryManager
chm.getChangeItemsForField(issue, "status").find {it.toString == 'In Progress'}?.created

This is already nullSafe. I.e. on create or on new, the find{}?,created will return a null Otherwise, it will return a valid timeStamp value.

BTW, you don't need that package line unless you save the script as a file in a folder like {JIRA_HOME}/scritps/com/onresolve/.jira/groovy/test/scriptfields/scripts/inProgressDate.groovy

[Steven F Behnke]

Agreed that likely cause is mismatch in format.

[Taylor Huston]

I put the same code into our Staging server and it didn't have any issues.

I also found that, despite the warning, the issues were being created. They kind of all appeared once I disabled the scripted field. Looks to be an indexing issue. I don't currently have SSH access to tail/view the logs directly, working on that and will get back to you.

Thanks!

[PD Sheehan]

You can also view the full log from scriptrunner built-in scripts.

Or, after execution, refresh the listener page and click on the execution icon that failed. Log messages should be in there.

[Steven F Behnke]

Hi Taylor --

Foremost, if you are receiving indexing failures, please be aware that this means the Issue was likely properly persisted to the database and is accessible via direct URL, but not visible on Boards or via Search because it is not indexed. Keep in mind, when you perform a reindex, you're likely going to see all of these issues "popup".

Secondly, you are likely seeing a log at ERROR level on the node you're executing this function on. You should be tailing the affected nodes atlassian-jira.log file at the time you press CREATE in order to capture that message. It's likely it will be very helpful to you.

I tried to reproduce the problem but cannot in my Jira instance. Can you load screenshots of: 

• The Custom Field CONFIGURE screen (where the contexts are set)
• The Custom Field's EDIT screen (where the searcher is set)
• The Script Field's CONFIGURE screen (where the code and the template are placed