I wish to have a custom field that has the same value for all issues and there is no reason to have it on the screen as it should not be selected or modified by a user.
It appears that in order for the default value to be set, the field has to be on the screen when the issue is created. It also appears that the field has to be on the edit screen as well, otherwise it gets cleared when the issue is edited and the field is not present.
This is a select list single choice field for reference.
Does the field HAVE to be displayed in order to set and maintain it's default value?
For additional background: this field is used in the ServiceRocket Connector to specify the Salesforce record type ID behind the scenes when creating the record in Salesforce. Since the destination object has multiple record types, I was told by ServiceRocket that the way to specify the record type is to create a select list field and insert the record type IDs in the field mapping configuration. In our use case, we will only ever be creating records for one record type, so users don't need to pick this.
there are a lot of fields that are use for WF automation and other purposes that are not shown on Edit and View screens and their values are manipulated with code - primarily via transition post functions.
To give you a popular example - I am setting the Assignee to be always the Reported in some workflows and the Assignee is not a field that is shown on the create or edit screen. So it can be done.
When you say "It appears that in order for the default value to be set, the field has to be on the screen when the issue is created. It also appears that the field has to be on the edit screen as well, otherwise it gets cleared when the issue is edited and the field is not present." this sounds strange and wrong, can you provide a concrete example?
Thanks for the reply. It sounds, based on your answer, that my original statement still holds true. That default values for custom fields only work if the field is on the screen. You have suggested a workaround that does not leverage default field values, just to be clear.
The WF automation suggestion is not ideal for me as it would require me to update and maintain the workflow for each project separately in order to accomplish this, whereas a default value applies to the field across all projects. Unless I am missing something here?
To answer your question, I created the field, set the default value, completed a mass update of issues to confirm that they all had that value in that field. Then, I removed the field from the screen. I proceeded to update about 5 issues (updating other fields, etc.) and then ran a query on issues where the custom field in question was blank and these 5 issues that I had just edited came up on that list.
It appears that by removing the field from the screen and then editing the issue, the field lost its default/current value and went back to null.
I hope this helps to clarify.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs