nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I avoid overwriting previous data when setting a default value using a behavior?

Jeff Ward

I have a behavior that enters a bug template into the description field of the issue when it is of type "Bug". However, I want to avoid having people lose information if they go back and change the issue type to Bug after entering information.

STR Example:

Click "Create", create issue screen defaults to the current project, Task
Enter information including a description.
Realize this is a bug, switches from issue type Task to issue type Bug.
Behavior kicks in and replaces the description with the bug template.

I'm checking for a previously filled in form field (using getValue) but the value is returning null always. Is there a different method I should be using?

Code:

import com.onresolve.jira.groovy.user.FieldBehaviours
import static com.atlassian.jira.issue.IssueFieldConstants.*
import groovy.transform.BaseScript

@BaseScript FieldBehaviours fieldBehaviours

if (getActionName() != "Create") {
	return // not the initial action, so don't set default values
}
def templateValue = """*Device / OS:*
*Test Account:*
*Precondition:*
*Steps to Reproduce:*
#
#
#
*Expected Result:*

*Observed Result:*

*Reproducibility:*"""

def descriptionField = getFieldById(DESCRIPTION)
def previousValue = (descriptionField.getValue() as String)?.trim();

if(previousValue == null || previousValue?.equals(templateValue)) {
	previousValue = "";
} else if(previousValue) {
	previousValue += "\n\n";
}

descriptionField.setFormValue(previousValue + templateValue)

Accepted answers

JamieA

You can't do this as an initialiser, because currently the form contents are not available in initialisers. Therefore you need to attach it to a field as in Jonny's example. There you can check whether the value is currently empty.

You can also use getUnderlyingIssue(), which will return null if this is the Create action (better than checking the action by name).

All comments

Jonny Carter_3nm6du

Odd. That script actually works for me. What version of JIRA and ScriptRunner are you using?

Here's some quick screenshots of how I configured it. Maybe you need to adjust the mapping?

Screen Shot 2016-09-07 at 1.33.10 PM.pngScreen Shot 2016-09-07 at 1.33.17 PM.png

Jeff Ward

I'm running as an initializer, would a validator be better? ScriptRunner 4.3.6, JIRA 7.1.2

Jonny Carter_3nm6du

Well, attaching the behaviour to the description field will seemed to make your script work, so... probably that's better than an initializer, for your use case? The initializers only run once when the form is loaded.

Jeff Ward

Initializers run when you switch types, the field validators run every time you switch on / off fields. I'd love for the initializer to know what's in the form after it's been loaded but it appears that's not a thing it can do.

I've had to modify the code slightly to work bound to the description field instead (to prevent issues when switching back and forth between different issue types)

import com.onresolve.jira.groovy.user.FieldBehaviours
import static com.atlassian.jira.issue.IssueFieldConstants.*
import groovy.transform.BaseScript

@BaseScript FieldBehaviours fieldBehaviours

if (getActionName() != "Create") {
    return // not the initial action, so don't set default values
}

def templateValue = """*Device / OS:*
*Test Account:*

*Precondition:*

*Steps to Reproduce:*
#
#
#

*Expected Result:*


*Observed Result:*


*Reproducibility:*"""

def descriptionField = getFieldById(DESCRIPTION)
def previousValue = (descriptionField.getValue() as String)?.trim();
if(previousValue?.length() &lt;= 0) {
    descriptionField.setFormValue(templateValue)
}

JamieA

You can also use getUnderlyingIssue(), which will return null if this is the Create action (better than checking the action by name).

Jeff Ward

I've switched over to this, but it looks like modifying the field this way turns off inline editing. Even changing the behavior script to add

descriptionField.allowInlineEdit = true

Doesn't seem to fix the issue. Is there something I'm missing to keep inline editing enabled as a result of this behavior?

Jonny Carter_3nm6du

That's deliberate. ScriptRunner automatically disables inline editing for fields that are marked as part of behaviours. The reason for this is that a behaviour can be complex enough that inline editing becomes unhelpful, even harmful in many use cases. Since inline editing can't make dependent fields editable, there's no way to cover one of the most common use cases for behaviours.

Jeff Ward

Sure, but is there any way to override that behavior? In this case the behaviour is not complex enough to warrent disabling inline field editing.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

jira

addon-com.onresolve.jira.groovy.groovyrunner

jira-administration

jira-core

behaviours