How to populate description field with template during create while removing template upon issue type or project changes?

Adam Barylak
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 16, 2014

So, i'm sure a lot of people have this request but I haven't been able to find a good effective way to make these templates for the description field dynamic as you change projects or issue types so that the user interface is still easy to use and they are only shown the template in the description field when it is needed.

I have attempted to do this using the Behaviours plugin, but this requires that i have a Behaviour for each project/Issue Type combination. (I have tried to have one generic behaviour "All projects/ All issue types", but that behaviour seems to get lost when you have others specific to issue types, which i have opened up a bug in the Behaviours plugin for this instance)

The other downside to using the Behaviours plugin for this, is that you have to put a behaviour on the Description field for ALL your current behaviours which then disables inline editing on that field, which is one of the most used fields when editing an issue via inline edits.

Now, i have read and tried some of the javascript only solutions, but i have not been able to figure out how to change the template as i change projects or issue types.

The way this should work is as follows:

  1. If Description is blank and project/issue type calls for a template, fill in template in Description field
  2. If Description is not blank and project/issue type calls for a template, check field against current templates, if match set to current template for project/issue type, else leave as is.
  3. If project/issue type does not have template, check description field against current templates, if match set to blank, else leave as is.

On top of that, inline edit should still be available on an issue if possible.

Looking for ideas or suggestions, anything may help. Thanks.

4 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

0 votes
Answer accepted
Adam Barylak
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 16, 2017

Wow, this is an old question that never really got answered.  I have since moved on to doing this in a different way.  We are running JIRA Server version, so I was able to install the ScriptRunner plugin fully (I'm not sure is ScriptRunner has the Behaviours functions in the Cloud version).

Look into the functions of the Behaviours part of ScriptRunner add-on.  It provides a way to set default values.  Obviously you'll have to conditionally set the default value as well as provide an opposing behaviour which would clear the description field or change it when switching to a different issue type or project since that can be done live on the page.

Look into writing a groovy script to be called by the behaviours with different functions.  That way you only have to change a single file instead of multiple behaviours in the future.

Here is a snippet of some of my code, and i just call the functions from the behaviour(s) as needed.

import com.onresolve.jira.groovy.user.FieldBehaviours
import com.onresolve.jira.groovy.user.FormField
public class DefaultDescriptions extends FieldBehaviours {
    public void defaultDescription () {
        log.debug("Clearing Description if applicable1");
        FormField descField = getFieldById("description")
        if(descField?.getValue() == ""
                || descField?.getValue() == "h5.Steps to reproduce\n# \n# \n# \n\nh5.Expected Results\n\nh5.Actual Results\n\nh5.Dataset\n\nh5.Screen Resolution\n\nh5. Additional Details\n"
                || descField?.getValue() == "h5.Test Steps\n# \n# \n# \n----\nh5.Expected Results\n"
                || descField?.getValue() == "h5.Purpose:\n\n\nh5.Setup and Test Data:\n\n\nh5.Additional Notes:\n\n"){
            descField.setFormValue("");
        }
    }
    public void engDefectDescription () {
        log.debug("Setting Eng Defect Description");
        FormField descField = getFieldById("description")
        if(descField?.getValue() == ""
                || descField?.getValue() == "h5.Steps to reproduce\n# \n# \n# \n\nh5.Expected Results\n\nh5.Actual Results\n\nh5.Dataset\n\nh5.Screen Resolution\n\nh5. Additional Details\n"
                || descField?.getValue() == "h5.Test Steps\n# \n# \n# \n----\nh5.Expected Results\n"
                || descField?.getValue() == "h5.Purpose:\n\n\nh5.Setup and Test Data:\n\n\nh5.Additional Notes:\n\n"){
            descField.setFormValue("h5.Steps to reproduce\n# \n# \n# \n\nh5.Expected Results\n\nh5.Actual Results\n\nh5.Dataset\n\nh5.Screen Resolution\n\nh5. Additional Details\n");
        }
    }
}

 

Then, you should also re-enable the ability to inline edit the description field (the behaviours add-on removes that functionality for fields in the behaviour configuration).  In order to do that, add the following code into the "Initialiser Functions" of your Behaviour:

def descField = getFieldById("description")
descField.setAllowInlineEdit(true)

I hope this all helps someone else looking for this.  Obviously if you can't upload script files to the Cloud, the solution will change to putt the script functions directly into the behaviour, but if you can't use behaviours in Cloud, then you'll have to find a different way.

UPDATE: Upon new information from the ScriptRunner team, I have found out that there is no default method for handling multiple behaviours on the same field active at the same time for a certain issue type/project/field combination.  This means, that you have to be extra careful with how you configure your behaviours to accomplish this entire functionality (handling changing of templates between issue types, and clearing templates for issue types that don't require them depending on user changes to issue creation).  Meaning that you either have to ensure that there is no overlap of your behaviours, or remove the description field from all behaviours, and add it to just one generic behaviour, and control the different templates in the code instead of the behaviour mapping.  In short, in order to get the correct template to display at the correct time, it requires some pre-planning before implementing a correct solution.

Deleted user June 11, 2017

Hi there Adam, 

From your post above you mention "Obviously you'll have to conditionally set the default value as well as provide an opposing behaviour which would clear the description field or change it when switching to a different issue type or project since that can be done live on the page.".

I am using ScriptRunners "Behaviours" on a Server JIRA installation and I am trying to figure out how to the part of "provide an opposing behaviour which would clear the description field or change it when switching to a different issue type or project since that can be done live on the page."

Can you provide some info on where/how to do this? So essentially I need to know what triggers the "Project" and "Issue Type" change every time those fields are changed on a live page??

Thanks in advance.

PG

 

Adam Barylak
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 15, 2017

@Parisa-

In my above code snippet, you can see that i have a "defaultDescription" function which tests of any of the other descriptions that are auto-populated and if found resets the description field to blank.  This function is then called in a default behaviour which i configure in the behaviour plugin.  I set that up by just creating a nearly blank behaviour and mapping it to All Projects and All Issue Types.  I also call this function from within any other project/issue type specific behaviours which should not default the description field.

In summary, you basically want to call the "defaultDescription" function of the script in any behaviour you do not want your description field to auto-populate with a template, then also have a global behaviour to catch all the projects/issue types you currently don't have a behaviour for.

Every time you change the project and/or Issue Type on the create issue screen, the behaviours re-fire as appropriate.  So, if you follow the above, you will have the description field getting populated with a template when needed and getting cleared out when not needed.

Hopefully that helps.

Adam

0 votes
Paul Stahlke March 19, 2018

The simple example in the ScriptRunner documentation for setting a default description works like a charm: 

https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html?utm_source=product-help#_setting_a_default_description

0 votes
Scott McDonald December 2, 2016

How would a rookie programmer add these questions/statements into the description box?

What we are checking:

What we are not checking:

Pre-conditions / Dependencies:

0 votes
Adam Barylak
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 26, 2014

Here is a sample javascript that i have tried to place into the description of the description field so that it would load on load of the create window.

<script type="text/javascript">
	function setDescription(){
	   if(typeof AJS.$("#description").value == 'undefined'
			|| AJS.$("#description").value == ""
			|| AJS.$("#description").value == "h5. Steps to reproduce\n# \n# \n# \n\nh5. Expected Results\n\nh5. Actual Results\n\nh5. Dataset\n\nh5. Screen Resolution\n"){
		  AJS.$("#description").val('undefined');
	   }
	}
	setDescription();
	var myElement = AJS.$("#project-single-select").parent().parent().parent().parent().parent().parent();
	//var myElement = document.getElementById('create-issue-dialog');
	if(myElement != null && window.addEventListener){
	 // Normal Browsers
	 myElement.addEventListener('DOMSubtreeModified', setDescription, false);
	} else
	 if(myElement != null && window.attachEvent){
	   // IE
	   myElement.attachEvent('DOMSubtreeModified', setDescription);
	}
</script>

I have tried to attach a function to the refresh of the create overlay when you change the project or issuetype, but obviously this is not working correctly for me. My plan would be to put code like this in each field configuration so that it would set or unset the description field template. However, the javascript only gets executed immediately after clicking on the Create Issue button to open the overlay. After that, and different Javascript when switching issue type or project does not get executed. The above code is a slight modification from another question on here that dealt with removing elements from an issue view screen (e.g. assign button, clone button, etc). If anyone has any experience with javascript like this, that would be great to get some help in setting the description field with a template.

 

Thanks.

 

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

TAGS
AUG Leaders

Atlassian Community Events