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:
On top of that, inline edit should still be available on an issue if possible.
Looking for ideas or suggestions, anything may help. Thanks.
Community moderators have prevented the ability to post new answers.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The simple example in the ScriptRunner documentation for setting a default description works like a charm:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.