Scriptrunner Escalation Service updating incorrerct custom field Edited

I have a custom Date Time Picker field, that is populated as part of a Post Function using the %%CURRENT_DATETIME%% macro from the plugin JIRA Suite Utilities.  This populates the field as expected and the data is stored down to the second.  In the DB it is stored like: '2017-11-17T09:56:53-0800'.  This works as expected.

 

I then have an escalation service which updates 3 other custom fields, but NOT the Date Time field.  This works as expected to update the fields I want however it some how also manages to update the Date Time field even though I dont have any script code to reference it.  When looking at the DB i see that it is updating the "seconds" portion of the date time to 00.  So from the above we go to: '2017-11-17T09:56:00-0800'

 

Since my escalation service runs as a CRON job and does not execute any transaction I'm not sure why the field is being updated.  Any ideas?

JIRA 7.2.7

ScriptRunner 5.0.4

 

 

 

1 answer

Can you post some more detail about your escalation service? It seems very likely that your escalation service is executing the workflow transition, which causes your post function to fire, but without the code/configuration of the service, I can only speculate.

Here is the majority of the escalation service code, I removed all the logic which determines the field values because they reference other systems/DBs.

I also included a screenshot of the service definition, with the user information removed.

 

Thanks

 

import com.atlassian.jira.bc.issue.IssueService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.customfields.manager.OptionsManager
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.IssueInputParameters

import groovy.sql.Sql;
import groovy.time.TimeCategory;
import groovy.transform.CompileStatic;
import groovy.transform.TypeCheckingMode;

import java.lang.Object;
import java.sql.Driver;

import org.apache.log4j.Level;
import org.apache.log4j.Logger;

@groovy.transform.TypeChecked(groovy.transform.TypeCheckingMode.SKIP)
@CompileStatic
void main () {
/**
* ....
* Whole bunch of code to determine field values
* ....
*/


/**
* Actually perform the updates
*/

if(fValue.toString() != 'null') {
ktField = customFieldManager.getCustomFieldObjectByName("Field1");
optionsManager = ComponentAccessor.getOptionsManager();
fieldConfig = ktField.getRelevantConfig(issue);
option = optionsManager.getOptions(fieldConfig).find { it.value == fValue.toString() };

issueInputParameters.addCustomFieldValue(ktField.id, option.optionId as String)
issueInputParameters.setSkipScreenCheck(true)
}

issueInputParameters.addCustomFieldValue(cfPI.id, priorityIndex.toString());

IssueService issueService = ComponentAccessor.getComponent(IssueService);
user = ComponentAccessor.getJiraAuthenticationContext().loggedInUser;
update = issueService.validateUpdate(user, issue.id, issueInputParameters);

if (update.isValid()) {
issueService.update(user, update, com.atlassian.jira.event.type.EventDispatchOption.DO_NOT_DISPATCH, true);
}
}

main();

 

es.png

 

es2.png

This is very curious indeed. The fact that it's keeping the rest of the timestamp indicates that the escalation service isn't causing the post function to fire, as that would update the minutes as well.

I'm curious if you can reproduce this using a much simpler script... maybe one that sets some unused custom field to a static value and does nothing else? If that doesn't cause the same issue, the problem is probably somewhere in the omitted code.

Another thing to look at: You're using the issueInputParameters object that gets injected into the binding automatically, then making calls to issueService methods that use that object as a parameter, as in this line:

issueService.validateUpdate(user, issue.id, issueInputParameters);

That same object gets passed to Jira services after the code executes. You might try either avoiding the calls to issueService.validateUpdate / update entirely (since ScriptRunner does a lot of that work for you) OR creating your own IssueInputParameters variable for your separate updates.

For example,

def myOwnIssueInputParameters = issueService.newIssueInputParameters()
//...add whatever parameters you need
issueService.validateUpdate(user, issue.id, myOwnIssueInputParameters)

 

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Julia Dillon
Posted Apr 17, 2018 in Jira

Tell us how your team runs on Jira!

Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...

809 views 2 19
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you