How do I pre-populate text to a description field on JIRA Cloud version 7.x?

[rosebud0911]

I have tried all the Javascript solutions I've found already and they only seem to add the code as txt to the grey'd out area beneath the text box (like a label).

[Ignacio Pulgar · Accepted solution]

You can do it by creating custom fields.

In order to do so:

1. Enter JIRA, press the 'g' key twice and type 'custom fields'.
   1. Click on the button 'Add Custom Field', on the top right corner.
   2. Select a text field (multi-line or single line). Click 'Next'.
   3. Give it a name and, optionally, a description.
   4. Click on Create.
   5. Select the project(s) checkboxes in which you want to include your custom field.
   6. Click on Update button.
2. On the Custom Fields page, find the name of your custom field and click on the icon in the right > 'Configure'.
   configure.jpg

   1. Click on the link 'Edit default value'.

   2. Type the description you wish to be populated as the default for that given field.
   3. Click on the 'Set Default' button.
3. Repeat this process again for each text field in which you want to have a different default value.

After that, associate your custom fields to the screens in which you wish to have them.

[pace_wstaves]

I want to do the same thing as other people have mentioned on here. Pre-populate the description with a template structure 

Steps to reproduce

Observed behavior

Desired behavior

Hopefully someone will see that there are several people here that desire this functionality, and help us achieve it, rather than beat us over the head with their opinions about custom fields.

[Nic Brough -Adaptavist-]

As before - JIRA doesn't do this natively, so you have to hack it.

I'm afraid for Cloud, there's no real way to do it, unless you start doing things with browser add-ons.

Custom fields are your only option, irrespective of any opinions.

[Fermulator]

One user mentioned it already, but here's the link:

https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html

Using "Behaviours" from the ScriptRunner plugin should exactly solve this request.

[Nic Brough -Adaptavist-]

Again, bad idea, and it's not valid for Cloud.

[Nic Brough -Adaptavist-]

Essentially, you can't - javascript hacks in JIRA are gradually being disabled, and the approach here is to get a good answer to "why are you trying to put useless data into fields?".  What are you trying to achieve by pre-populating the description?  Why haven't you split that up into custom fields which do take defaults?  What use is a description people will just accept instead of putting good data into?  Why don't you just remove the description field if you're not going to ask people to think about its content?

[rosebud0911]

Because it isn't pre-populating that actual data rather the information for the standard answers that need to be given on each issue that is filed.  It is basically a template that MUST be filled out on every ticket.  A gentle subtle ... in your face reminder of what is required to be in that field.

[Nic Brough -Adaptavist-]

Ah, all the wrong answers as usual. If you pre-populate a text field, people will ignore it. If you need it to fulful a certain format, people will overwrite that too. Convert it to a set of fields, leave them blank (unless you genuinely do have solid defaults for them) and set them mandatory to force people to enter them and think about it. In places where people set text defaults, you find that between 60% and 99% of issues will have the defaulted text and nothing else (the more complex you make it, the higher the percentage as a general rule).

[Ryan Thomas]

We use Bug issue types.
I want my testers to enter a standard format for bugs in the description of the bug. I don't want to add another custom field for something the Description of the bug should handle.

You cannot do this is acceptable.

You shouldn't because my arbitrary experience tells you not to isn't always acceptable. 

STEPS TO REPRODUCE:
1.
2.

EXPECTED RESULT:

ACTUAL RESULT: 

This should be available in Cloud version.

[Nic Brough -Adaptavist-]

Same answer - you're going to get large amounts of pointless rubbish if you try to inflict this on users.  Consider doing it properly.

[Mikkel Bækhøj Christensen]

Trying to force users into populating many mandatory fields that are mostly - but not always - applicable, is a surefire way to make users enter pointless rubbish while cursing the stupid rigid form at the same time.

Pre-populating the description field, with a useful, helpful template that both reminds users of what they should be writing and assists with nice formatting works great because it actually makes the work of the user easier while still allowing the user to use a better format in special cases.

I know it works, not from personal opinion, but from personal experience with a team of software developers that I was leading. We used Default values for create issue screen which unfortunately isn't available for Cloud, only for Server.

Nic, you are entitled to your opinion, but don't presume to know every situation that Jira users have better than they know it themselves. Scriptrunner is great, BTW.

[Kathy Barton]

I have to respectfully disagree with you, Nic. I have been using the prepopulated Bug format listed above for years and both the testers and the developers love it. I've only had a few people overwrite it and correcting them was a great teaching opportunity. 

I'm working with a client now that is having a lot of trouble remembering the User Story format "As a ___, I want to ____ so I can ____". I was hoping to prepopulate that into the Description field for them. 

[Nic Brough -Adaptavist-]

All I can go on is my experience of finding tens of thousands of stories with nothing by the default text in them.  In some places, it might be fine.  In the places I've seen, it fails.

[Ryan Thomas]

What are you trying to achieve by pre-populating the description?
I thought I was clear, maybe I wasn't.

We want the description field to be more guided to help adherance to convention.

We like the description field being a single searchable discrete field. Most users follow the format, but it would be great for training and onboarding to have an established format for them.

Why haven't you split that up into custom fields which do take defaults?  
See above.

What use is a description people will just accept instead of putting good data into? 

I don't think you read, or understand what I described. Each bug is unique. However the very basic outline of: 

Steps to reproduce:

Expected Result:

Actual Result:

The format above is already  being followed, but some users forget some times and new QA users have to be onboarded.

[Ryan Thomas]

Why don't you just remove the description field if you're not going to ask people to think about its content?  

That is one option. We're already functioning well and sufficiently, but I would like to improve and enhance our current workflow.
If this isn't the forum or place for these types of inquiries, could you please direct me to them?

Thanks!

[Nic Brough -Adaptavist-]

No, you're in the right place.  I think we've covered your recent comments already.

[Jeff Xanthos]

In the end, is it possible to do (Cloud version) as outlined above by Ryan Thomas? :

Ie set some deafult structure/guided description body that users can follow?

STEPS TO REPRODUCE:
1.
2.

EXPECTED RESULT:

ACTUAL RESULT: 

[Nic Brough -Adaptavist-]

No, it's not possible on Cloud, you can't inject the code.  Do it properly, with separate fields.

[Jan Zahrádka]

Hi,

the same as guys above, I have exactly the same need.

Pre-fill template while creating bugs:

STEPS TO REPRODUCE:
1.
2.

EXPECTED RESULT:

ACTUAL RESULT: 

I am one of many of Team leaders who really APPRETIATE if JIRA  allows us to decide which way is more suitable in our environment.

We do have separate fields for Environment, operating systems, type of tests and others. But there is essential need of pre-filling description field with a template of what-you-should-not-omit-if-you-are-describing-what-was-wrong.

Nic, I am very sad of you attitude. We don't want to inject code. We want the ability to pre-fill the description field. If there is an option in the field edit mode, it would be the best solution.

Your proposal maybe works from developers perspective, but absolutely doesn't work from team process perspective.
Let Jira is tool and we master the processes. Not in opposite.

Thanks.

[Nic Brough -Adaptavist-]

Same answer - JIRA doesn't do this natively, so you have to hack it.  I'm afraid for Cloud, there's no real way to do it, unless you start doing things with browser add-ons.

I'm glad it doesn't let you, because it's a bad way of doing things, simply because you end up with a lot of junk and defaulted values, but that is a different discussion, and explained in full above.

[Mario Tacke]

Really sad to see this blanket statement answer over and over without considering why people do it. I'm in the same boat, I want to make it easy for my users and gently remind them of necessary information. Nobody in my organization wants to battle with a complicated form when all they need is a few lines of text in a text template.

We do the same with our GitHub pull request templates: We have some pre-populated text that reminds the submitter to fill in information that makes understanding the issue much easier.

[Nic Brough -Adaptavist-]

I'm not sure it's fair to say the reason people ask is not considered - I think it is, and I think we do mostly understand why people want to do it.  There's not a lot of discussion on it, because the "why" is not the issue.

The discussion has spent more time on the problems it causes and why people like me have spent so much time cleaning up the mess it tends to make.

[Martin Unsal]

Nic - I think it's time to maybe consider that in this case you might be wrong. I mean, really consider it. Is it possible that your reaction, based on your extensive experience, is not actually relevant to the suggestion that people are making? That there's a use case here you haven't seriously considered?

In my 20 year experience with software project management at numerous Silicon Valley companies, there is no single step which is more conducive to good bug reports than the exact template that keeps getting mentioned in this thread:

STEPS TO REPRODUCE:
1)
2) 

EXPECTED RESULT:

ACTUAL RESULT:

There's a reason so many people use this. It works.

Now I'm willing to be open minded too. Can you propose a design using custom fields or other available features in Jira to accomplish the same result without a default template for Description field? That when a issue is filed with type Bug, that the victim of the bug is gently nudged to structure their bug report in a way that is clear, systematic, and comprehensible to both developers and testers? That this structured observation still provides enough flexibility for users to bend it to their needs and the idiosyncracies of each bug, or ignored if it doesn't apply at all? And it is presented front-and-center where everyone who looks at the issue will focus on the most important characteristics of the bug? I am legitimately interested in your answer.

[Nic Brough -Adaptavist-]

I'm afraid you need to read the rest of the conversation.  It's all covered there already.

[Deleted user]

I will need to move to the server version for this functionality. Well if this is the case and users are given helpful nudges or hints on what and where to add necessary information I see no downside.  

[Ryan Thomas]

Ignore: :/

[Nic Brough -Adaptavist-]

This does not work. It actually makes the problem even worse.

It does add a pre-filled description on creation of the issue.  After you create it.  Every issue done this way has the default text in the description, and users have no reason to go back and edit it.