Auto-Description overwriting on field change

[Alan Lavery]

Hi,

We're currently using Behaviours to create template descriptions for various projects. Whenever we are creating an issue, edit the description field and then change another field the description resets to the template.

The issue also occurs if the form is submitted but the user has left out a required field. When the form reloads the changed text is still there but then resets to the template almost instantly.

We have included the suggested underlyingIssue? code from the documentation in the Initializer Script:

def desc = getFieldById("description")

def defaultValue = """Description
 Template""".replaceAll(/ /, '')

if (! underlyingIssue?.description) { 
 desc.setFormValue(defaultValue)
}

Has anyone had this issue before and figured out a fix or could point me in the correct direction?

Thanks

[Daniel Yelamos [Adaptavist] · Accepted solution]

Hello Alan.

As I understand you have two parts to your issue:

Part A: the form calls the initializer on the field in the behaviour when you change another field:

Part B: When the form is wrongly entered, such as when there is a required field missing, it calls the initializer again.

For Part A:

(the first import statement is to make sure that the DESCRIPTOR field works)

import static com.atlassian.jira.issue.IssueFieldConstants.*

def desc = getFieldById(DESCRIPTION)

def defaultValue = """Description
Template""".replaceAll(/ /, '')

if (!desc.getValue()) {
    desc.setFormValue(defaultValue)
}

This should do the trick. “underlyingIssue” calls the value of the issue object, which you have not created yet, because the form is not summited. So that is why it always sets it up to null.

The desc.getValue accesses the data in the form, rather than in the object. I tested it and it works on my environment, give it a try and tell us how it goes.

For part B if the behaviour is an initializer, it does behave as you say. However, if rather than setting up an initializer, you set up a field behaviour, then it should work as you expect, and even if you switch from different types of issues, you data should remain.

I hope this helps and if you need anything else don’t hesitate to ask.

[Alan Lavery]

Hey D'Yelamos,

Big thanks for your help. The solution you posted works when I put the script into the Description behaviour field. 

I am stuck on one last part of issue which is when the create issue is being made in a new window (not the pop up lightbox window) the description template isn't populated on load. Does this screen need to use the Initaliser Function in order to populate?

[Daniel Yelamos [Adaptavist]]

Hello Alan.

I can verify that it is as you state and this has been added as a bug in the ScriptRunner log. Thanks very much.

You can access the issue in the link below to check its status.

https://productsupport.adaptavist.com/browse/SRJIRA-2212

It will be resolved in future releases.

Cheers!

[Alan Lavery]

Thank's for that Daniel. I'll keep an eye on the bug for when it's fixed.

[Alan Lavery]

Hey Daniel,

I have encountered another issue with this fix. Using the script above if we have different templates for a Story and a Bug on the same project when switching between issue types the template won't change.

Is there a way to check for IssueType or Project change?

[Daniel Yelamos [Adaptavist]]

If by change you mean that it does not get reset, then yes, it won't. That happens because it is a field behavior. If you want a reset on every form change, you should change the field behavior to an initializer. 
Please tell me if this helped.

Cheers!

[Alan Lavery]

Unfortunately we can't use the Initializer to change the description due to the initial issue described above. If we use the Initializer to change the decription field it will reset whenever we change another field or reset if submitting with a missing required field.

It appears that we will have to decide on which issue we can live with unless we can determain when the issuetype or project field changes.

[Sasha Solig]

Hi Daniel,

I know this was marked as resolved some time ago, but I find I am having a similar issue to that mentioned by the OP. This occurs only when the create form is in full screen mode and when the Create button is clicked before all required fields have been entered. The result is that the default value in the Behaviour Initialiser script overwrites the description modified by the user.

The form has to be in full screen mode because I have an external link on our intranet that opens JIRA on the create form for this particular project / issue type. Using this technique loads the Create form in full screen mode and I don't believe there is any way to open it in popup dialog box mode from an external link.

I tried the solution suggested above and found that desc.getValue() always returns false, even after the initial page loads and the user has modified the default description text.

I believe my Behaviour configuration is the same as the OP, where the description default value is set on the Initialiser and is mapped to a single project / issue type.

Has anyone come across this issue and/or a solution?

[Daniel Yelamos [Adaptavist]]

Did this solve your issue?