After much research, it has been made clear that we cannot update the main description field with default text.
So I now see that I will need to create a custom field for thus purpose.
I have created a custom field, I have given it my default text, I have even adjusted its location on the ticket creation screen. But I'm struggling to get it to be correct on the VIEW page.
What I want: It should look & function just like the main Description field. I want this custom field to be in the same exact location as the main Description field (I will then remove the description field from view).
What I am seeing: The custom field is showing up in the top section with the status, labels, components, type, priority, etc.
I know there are plugins to help with this, but none of them seem to be compatible on the cloud (which is where I am).
Just to complete Gabriel's answer, here is a use case I had a hard time with (but found a pretty clean solution) :
1. Click on "Create new ticket"
2. I want to see "Description" field with prefilled text inside it (Create screen)
3. I want to see the final content inside the "Description" (View screen)
4. I want to see "Description" when I edit my ticket (Update screen)
The main contraint here is that Description is a core field in Jira, which cannot be touched at start of the workflow.
What I've done for a quick solution, is to add a "shadow" description:
1. Create a custom field named "Description", multiline text, with wiki render configuration
2. Replace the native "Description" by your custom "Description" in the Create Screen configuration
3. Set default value you want for your custom "Description" (the text which will appear when the modal opens)
4. Go into your workflow configuration, and at the first transition (for me it was a transition between first point and "To be implemented" state) add 2 post functions at the top of the post functions list (rank 1 and 2).
- First post function : Copy value of custom "Description" inside core "Description"
- Second post function : Delete content of custom "Description"
5. Configure your screens like following
- Create screen : must have your custom "Description" only
- View screen : must have the core "Description" only
- Edit screen : must have the core "Description" only
This way, when you click on "Create", your ticket will have the content you wrote inside custom "Description" into the core "Description" and the custom "Description" will not be shown because there's no content inside it.
For the other screens than Create screen, you just have to use the core "Description" instead of your custom "Description", we don't need the shadow Description anymore once the ticket is created.
Hi, @Julien Rubiano thanks for the awesome reply.
Just did what you described, but with a minor tweak, since I had to name my custom field "Description X" otherwise the post function dropdowns would only display one "Description" field, making it impossible to select a source and a different destination.
After everything was set up, I just renamed the custom field back to "Description" and it works
I tried following the steps described by @Julien Rubiano but I can't seem to understand from where I can configure steps 4 & 5 from his post.
I am new with configuring JIRA Cloud and I would really like creating templates for the description field. At the moment, with what I've done, I've created a new custom field, but it doesn't look the same as the original Description field (i don't have the menu for formatting the text):
Also, the texts that were previously in the description field are now gone.
Can you please help me?
I am trying to setup a JIRA custom field to appear on the create issue screen to look like the Description field and then when the issue to created to copy the value from the custom field to the actual description field. I followed @Julien Rubiano details but I can't get the post functions to work. The aim is to have a 'template' for the description field.
I have created the post functions as described on the 'create' for the transition. However the Description field never seems to get populated. It doesn't seem to matter what order the additional post functions are. Or if I try and write to a different system field.
Is there a limitation here I am missing?
I am attaching the configuration I have for the post function that is supposed to make the copy - I get the same result -ie. nothing gets copied no matter which renderer I use for my custom field.
@Ana Maria Manea sorry for the delay.
Post functions are available in your workflow configuration, when you click on a transition (the arrow beteween 2 status).
@Nick Foster I'm not really sure where's your issue.
To clarify : you first need to set a default value to your custom description field (like "Here is the description of your issue, please send all mandatory informations").
To avoid any confusion, lets say your custom description field is called "Custom description".
Now you have to parameter your "Create screen" with "Custom Description" instead of "Description".
Because "Custom Description" has a default value, it will be populated at creation.
Now you dont want to stay with "Custom description", you want to go back with "Description". That's where post-functions are usefull.
In your workflow, you take the first transition (between the big dot and the first status) and you create a post function to copy the value of "Custom description" inside "Description".
You create an other post-function to delete content of "Custom description", because you don't want it to be shown anymore.
You need "Custom description" in "Create screen" only, all other screens keep "Description", which has now the wanted value.
Don't hesitate to ask step by step if you're blocked.
@Nick Foster Did you ever resolve your issue? If so, can you share how?I am experiencing the same thing. All steps work (including the post function to clear my custom description field) except for actually getting the info to successfully copy into the core "Description" field. I tried flipping the order (clear then copy, copy then clear), as well are oriented the new post functions in different orders ahead of the native post functions, but that did not seem to work either.
I am adding the post function on the "create" transition, perhaps that is not the right transition to trigger?
@Julien Rubiano This is a sweet solution! Thanks!
As a side note. Since I wanted to have different templates for the different item types, I just created a set of "Bug Description Template", "Story Description Template", etc, fields and this way I could set the default value separately for each item type.
@Julien Rubiano I really like this solution and have it working. But I now realise it doesn't work when you clone - it gives me an error "Unable to clear field" for my custom description. And I think because Clone uses the same workflow as Create, this solution isn't going to work?
@Matt Stephens I skipped that step in my setup. I don't clear out the custom field where I have my template text set up and I can clone without error. I didn't really see a reason to clear out text in that custom field I'm never displaying again after issue creation, so I just didn't do it.
oh hang on though @Ryan Cabanas , it means the description on the clone gets replaced with the template as well right? That feels like it could be annoying if someone actually wanted to copy the content. I guess they could just copy the text before hitting clone, but would have to remember to do that.
@Matt Stephens Just an update for you. You can work around the problem of "the Description from the original issue doesn't get copied over to the new issue after cloning" by using an automation.
The only downside I've found with the automation, though, is that when you are first presented with the new issue after the cloning completes, you don't see the updated "Description" field content in the new issue (which did indeed get copied from the original issue's "Description" field) until you manually refresh the page.
@Matt Stephens Ha! I'm one-upping my previous approach. :)
You can get around the need for a manual refresh by using a webhook. Set up your automation to trigger on a webhook. Create a webhook that points to that automation. Modify your workflow transition with another post function that uses that webhook and put it right after the "Creates the issue originally." post function.
Thank you @Ryan Cabanas from bringing some other clean solutions to this need :). I'll try the webhook I guess.
The main thing to remember with automation rules is the 1000 calls limit, because an automation rule is triggered even if there's no action to perform in your rule.
You can try to use post functions to set up a default text on the Description field.
This post function would update the value of the field once the issue is created, for example. Using this, every time that specific type of issue is created, the Description is set with a default value.
In the below documentation, there are more information, regarding to using post functions.
That's an interesting solution. However I'm looking to setup more of a template.
So each time you go to setup a new ticket, there are some default values in the description field meant to guide you on how best to fill out this field. So this can't be populated once the ticket is created, but rather on the first screen when you are first filling out the ticket details.
The Workflow Essentials plugin for server has an outstanding function, "Default Values for Create Screen". It's super easy to use and allows you to specify a different default for each issue type in a project --- even if they're all using the same screens and schemes.
Sadly, it's not available for Cloud and I haven't been able to find an equivalent add-on or technique.
I made the set up to set value default in field description, just as you indicated, and it worked fine.
But I would like to set up a different value default for two different issue types (Story & Bug). I tried combining both issue types in the same post function, but only it worked with one, it depends on the position the rule in the list of post functions. Can you help me with this?
I have the same problem. Been trying to use different fields for each type but they are not removed when you switch type even if the only thing in them is the default text so it becomes messy very quickly.
Hoping this can be addressed soon, we are really missing our server version!
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