Change description before create issue

Question

Hello.

I try the automation feature to add a description to my issue before its creation.

I created a rule: When I create an issue -> and issue type is BUG -> and Reporter I am -> then description files has my text.

Now, this script runs only after the task is created, and I need to reopen it to make changes. So as I understood, all triggers are applicable for created issues, not for the current?

Question: How to immediately change the description field when all fields equal my values?

Lynne Ratcliffe · Answer

Konstantin, you could vote for this issue that’s only been open 18 years to try to get this as out of the box functionality

Ignacio Pulgar · Answer

Hi @Konstantin Zhabko ,

The way in which we cover the need for prepopulating text to be used in the Description field consists of the following:

* Create a new custom field of type Paragraph (also known as Text (multiple lines)) named Form-1.

(Note this field can be potentially re-used once per each Jira project in which you need to use a description template)
* Add Form-1 field to the Create Issue Screen of your project(s), ensuring it is not present on any of the Edit and View screens.
* Configure the custom field context (or create a new one) for the Form-1 field to narrow the scope just to the project(s) where exactly the same template would be needed.

Once configured, click on the link to edit its default value for that context, which will we the prepopulated text on the Form-1 field for that project(s).

Note this default value supports wiki notation format. If you noticed the field didn't render the wiki format, then you may change to the renderer in the appropriated field configuration.

* Now, configure an Automation rule triggered by the creation of a new issue, add a condition so that it only performs actions if the issue is of one of the appropriated types, and select the Edit issue action to update the Description field to concatenate the Form-1 and the Description values like this:

---

{{issue.Description}}
* Optionally, add a new action to clear the Form-1 value afterwards.

I like to do this, since just the Description field should be used from the creation of the issue onwards.

Also, because there would be less stored information, and less data to re-index.

After having configured it this way, you will see the Form-1 field with the prepopulated text, and then copied to the Description field, preserving any contents added to any of both fields.

Note that in our solution, we have both the Form-1 and the Description field present on the Create Issue Screen.

You might be tempted to remove the Description field and leave just the Form-1 field, since its content is going to be copied to the Description field, but we consider better to keep both fields, since some features rely on the presence of the Description field on the Create Issue Screen for being able to populate the Description field.

Please, note we use Form-1 field just as a temporary element so that we can achieve having prepopulated text to be included in the native Description field. This is a workaround to the fact that only custom fields can be set with a context and a default value.

We do NOT recommend using Form-1 instead of the Description field.

The Description field should be present in all issues of all Jira instances. This is a way to ensure no information is hidden when moving an issue to a different project with a different configuration.

In that sense, the native Description field should act as a universal field, common to all projects.

If you use custom text fields to contain relevant information, note some issues would effectively hide relevant information if they were ever moved to a different project which lacked those custom fields added to their screens, or which didn't have a field context configured.

That's another important reason for not using custom field of Text (multi-line) type, since that info should just be included to the Description field to ensure the info availability in all potential issue lifecycles (which potentially include moving an issue to a differently configured project).

This method has been very useful for avoiding the creation of many new text fields, since they don't provide any value for reporting purposes.

Hope it helps.

Konstantin Zhabko · Answer

It's hard to believe that Atlassian doesn't have its own templates for my case.

So, there is no other idea?