Feature #643


Issue description templates

Added by Yonni Mendes about 16 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When opening new issues it would help guiding the user to be as detailed as possible if an administrator could create a predefined template per tracker (per project?). Such a template need only be displayed as stand in text in the description field so that the user can then replace template parts with the actual input.

Related issues

Related to Redmine - Patch #2931: Templating for description of new tickets by TrackerNew

Related to Redmine - Feature #6715: Issue templatesNew2010-10-20

Has duplicate Redmine - Feature #12807: Add template per project for new issueClosed

Has duplicate Redmine - Feature #3153: Default description textClosed2009-04-10

Has duplicate Redmine - Feature #3594: Custom default value of the description fieldClosed2009-07-07

Actions #1

Updated by Thomas Lecavelier about 16 years ago

I don't think it's a "want-have" feature:

Even if it should be a good idea to teach BTS usage to new users, they soon will be proficient in using it, so entering an issue using n pages will become time-consuming. Organizing a small meeting presenting the tool with some real-usage of the tool for each attendee should be more valuable.

(or maybe I haven't understand your idea :) )

Actions #2

Updated by Ale Muñoz about 16 years ago

+1 for this.

What he is suggesting is this:

- When the user clicks on "New Issue", the description field is pre-filled with a text like this:

What you did
Please describe what you were doing when you found the issue

Expected result
What were you expecting to happen?

Obtained result
What happened instead

Please tell us what is your operating system, version, browser, etc...

(or words to that effect)

Check and you will understand. That form is a masterpiece of design, and is used a lot like a good example of how things should be done : )

Actions #3

Updated by Jean-Philippe Lang about 16 years ago

Check and you will understand

You can have a pretty close result using custom fields.

Actions #4

Updated by Adam Bates over 15 years ago

I was wondering if this suggestion would be revisited, as for a consistency reason it would a great feature. We have three very different trackers which have three different purposes. It would be good to provide a template for the user to provide verbose responses within a structure.

Actions #5

Updated by Light Kong over 13 years ago

Similar request to #2931.

Actions #6

Updated by Mischa The Evil over 13 years ago

  • Subject changed from Description templates to Issue description templates
  • Category changed from UI to Issues

This is indeed related to patch #2931, which is related also to issue #1138 which itself seemed to be a duplicate of this issue. I've closed #1138 in favor of this older issue.
I've also modified this issues properties subject and category to make it easier to find.

Actions #7

Updated by Erwin Mueller over 13 years ago


It would be great if you can specify a template per project and one to each issue category (bug/feature/support).
For example, what I like to have for issue type feature:




You can't have this with custom fields, because if you add custom fields, they will be under the description text field, below the standard fields, above the files upload field.

Actions #8

Updated by Damien Couderc over 13 years ago

Hi all,
It would also be even more useful if it was possible to have multiple templates for multiple kind of issue of the same tracker.

Actions #9

Updated by Antoine Roux about 13 years ago

Yes, I would love to have that as well. One template per tracker would be perfect in my case.

Actions #10

Updated by Sylvain Guimond about 13 years ago

+1 It would be useful!

Actions #11

Updated by Sunil Babu over 12 years ago


Actions #12

Updated by Josh Davidson over 12 years ago


Actions #13

Updated by Terence Mill over 12 years ago

Templates shall support wiki marcos also

Actions #14

Updated by tim lin over 12 years ago

+1, it would be very useful.

Actions #15

Updated by Mike Rötgers over 12 years ago

+1, indeed very useful

Actions #16

Updated by Andrey Zubkov over 12 years ago

+1 vote

Actions #17

Updated by Slan Buas about 12 years ago


Actions #19

Updated by Anonymous almost 12 years ago

+1 vote

Actions #20

Updated by Jonas J over 11 years ago

+1 needs to be on trunk

Actions #21

Updated by Etienne Massip about 11 years ago

  • Target version set to Candidate for next major release
Actions #22

Updated by Rodrigo Ramalho about 11 years ago

+1 vote

Actions #23

Updated by Olivier Houdas almost 11 years ago

+1 vote
We had it in our previous BTS (home-made), and now that we are shifting to Redmine, this would be greatly appreciated.
Note that we allow everybody in the company to enter bugs, hence the need to be a bit directive on the description.

Actions #24

Updated by Matthew Houston over 10 years ago

Not sure if the template ticket should have been closed as duplicated.

I think this particular ticket is already addressed by the custom fields. If that info is required then a custom field can be created and set as required?

Templates on the other hand are a different matter. For instance we are managing store installations with Redmine and to be able to have a template with pre-filled relationships and sub-tasks based on different criteria that the user could select would be great.

At the moment we just have an existing issue with all sub-issues created and linked, but it doesn't cover nearly enough, having the user select from a list would be awesome! While it is handled currently by a plugin, the rapid rate of releases is seeing a lot of these plugins just fall by the wayside unfortunately...

Actions #25

Updated by Anonymous over 10 years ago

+1 for a template per tracker and per project

Actions #26

Updated by Gurvan Le Dromaguet over 10 years ago

+1. Have been using it for a long time the patch at, simple and working !
UPDATE: I am wrong sorry, there is a bug: when changing the Tracker of the new issue, template is not updated.

Actions #27

Updated by Ilya Demenkov over 10 years ago

+1 vote.

We are currently using plugin as advised by John McBade at #11210 for this, but its features are limited, not not mention it's better to have such feature built-in.

As I've described in #11210, such feature should allow to set default values for most fields of an issues, not just for its description.

Actions #28

Updated by Alessio Pollero over 10 years ago

+1 Vote

It should be a must !

Actions #29

Updated by Masumitsu Hatta over 10 years ago


Actions #30

Updated by Massimiliano Donati over 10 years ago


Actions #31

Updated by Jan from Planio over 10 years ago

We've discussed this at Planio at lengths and the verdict was we don't think it's a good idea. It will create large chunks of unstructured text and possibly boilerplate content that cannot be queried against or otherwise be used.

In my opinion, the world should be as structured as possible and we already have custom fields for that: all the questions one would ask in these "issue templates" should actually become custom fields. What's even better: you can make them mandatory, searchable and things will just generally be much better than with templates.

Actions #32

Updated by TridenT Job over 10 years ago

I would like to use template for my 'backlog' and 'story' bug trackers.
Today, the template is store in a wiki page, and is copy/paste every time.

Template for trackers enables:
  • help the submitter to structure the feedback
  • Give directions, advices to submitter
  • same format for ticket
  • better than custom fields as it is open to any formatted text
Actions #33

Updated by Christian Dähn over 10 years ago

There are reasons for, but even against custom fields.

E.g. if you have different types of tickets like "service case" and "feature request".

For "service case" the description has to answer some questions, which are EVERYTIME free text answers (what did the customer report? what are possible reasons for the problem? what are the next steps? what is the solution?). When we search for keywords it's not predictable in which of these questions/sections (or: custom fields) these keywords occurr. Therefore we just search the issue description to filter our results - which is efficient for searching, as for creating/editing.

For "feature request" non of the above questions/sections (or: custom fields) can be reused - there are different questions which are entered as free text. So it's very hard to find custom fields, which match all or even most of the description sections of different ticket types.

Further we discussed this topic with our devs and users - with some experiences with issue templates and many custom fields in our previous Trac system. As result the users were happy that they didn't have to face with the big number of form input fields like in Trac (where we splitted our discription into different custom fields) and love the (by url passing filled) description template, where they only have to replace some placeholders with the content.

So: For some cases custom fields is the cleaner and more effective approach, for some cases issue templates do a really better job (covering more than just the description).

Hope this point of view helps a little.


Actions #34

Updated by Fred B over 7 years ago

This can be done in sharepoint when creating project. A project template can be choosed and it create task, user, etc.

In Redmine, this would be particulary usefull to have a template for particular issues, that would auto create sub-tasks and checklists.

This would be a really valueable feature.

Actions #35

Updated by Toshi MARUYAMA over 7 years ago

Actions #36

Updated by Toshi MARUYAMA over 7 years ago

Actions #37

Updated by Toshi MARUYAMA over 7 years ago

Actions #38

Updated by Go MAEDA almost 7 years ago

  • Has duplicate Feature #3594: Custom default value of the description field added
Actions #39

Updated by Mateus Demboski almost 7 years ago

+1 for a template per tracker and per project

Actions #40

Updated by Mateus Demboski almost 7 years ago

I think that this issue can be a good feature to the next 4.0.0 Redmine version, no? =P =)

Actions #41

Updated by Go MAEDA about 5 years ago

  • Target version changed from Candidate for next major release to Unplanned backlogs
Actions #42

Updated by Greg Christopher over 4 years ago

This feature has been asked for in excess of 10 years.
Several duplicate bugs have been logged, showing wide support for the ask.

I see this is moved to unplanned backlog if I understand correctly. It should be a must-fix.

The description field is free-form. Thus,from many different customers and each customer having different users, I see about 20 different ideas about what forms a complete description. And none of them are what we need, which is expressed perfectly in comment #2. The problem is that with B2B deployments, there is no control over what someone enters into redmine and the reduced verbal/human interaction makes this difficult to do.

Although we are using this as a B to B solution, a larger company like IBM would experience similar issues with a geographically diverse set of users with different styles.

Trackers/Projects tend to have the same types of issues. The ask is only for including per project so it is only used when necessary. And putting a concise template per tracker will not hurt search- it will help.

Some misconceptions in the processing by the Redmine team:

-The conception that a company internal discussion can solve consistency issues in the description field. Not only do project-internal groups vary in size and location from case to case (sometimes different time zones), the whole reason for web forms with mandatory fields is to ensure consistency. This field - the most important one - has no way to do that today. Forms are meant to ensure minimum necessary information in the absence of a human being present.
-The conception that Template text will fill the Redmine description database with identical template text. This is not true, templates are meant to be replaced with the text they template. As an example:

A [Problem your business is experiencing]
B [Preconditions]
1 [1st step to reproduce]
2 [2nd step to reproduce]
Expected Result:[what you expected to see]

Most of this text is replaced with wording specific to the problem as suggested by the use of brackets.

My team wastes literally 100 hours a month due to inconsistency in problem reporting from our customers. We have increased the # of mandatory and custom fields, but there is no way to create a set of custom fields to handle a 1 to N set of problem steps. This MUST be done with templates.

This was as much a must-fix 10 years ago as it is today.

Actions #43

Updated by Yuuki NARA over 4 years ago

Can you solve it by using the following plug-in?
This plugin is very popular among Japanese Redmine users.

Actions #44

Updated by Greg Christopher about 4 years ago

Sorry for the late reply- of course that plugin should work.

The issue is that our redmine instance is cloud hosted. We are negotiating with the providers to see if we can get it added, thank you.

The cloud hosting situation underscores why it's important that this feature be available by default. Not everyone has the freedom to add plugins.

Actions #45

Updated by Akiko Takano about 4 years ago

Hi, thanks for all and all the contributions to the long-term success of Redmine.
I maintain the small plugin mentioned above, but personally I would be very happy if this feature was implemented in Redmine itself :)

Recently, I added an experimental feature in the latest version that sets the core fields and custom fields as well as descriptions.

But I don't know if this feature will meet everyone's needs.
Could you try out the new features of this plugin if interests?

I'm glad if everyone finds it really worth it and would like to send more detailed feedback and patches to Redmine instead of the plugin.

Actions #46

Updated by Ryoh HAMADA almost 4 years ago



Also available in: Atom PDF