You can do it by creating custom fields.
In order to do so:
Click on the link 'Edit default value'.
After that, associate your custom fields to the screens in which you wish to have them.
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
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.
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.
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.
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).
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:
This should be available in Cloud version.
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.
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.
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.
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?
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:
The format above is already being followed, but some users forget some times and new QA users have to be onboarded.
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?
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:
the same as guys above, I have exactly the same need.
Pre-fill template while creating bugs:
STEPS TO REPRODUCE:
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.
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.
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.
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.
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:
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.
One user mentioned it already, but here's the link:
Using "Behaviours" from the ScriptRunner plugin should exactly solve this request.
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.
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events