Here is my work-around for this:
I added a transition named "Set Due Date" to the workflow which starts from the status "In Progress" and ends also in the status "In Progress". Then I created a new screen, named it "Set Due Date Screen" and connected it to the transistion.
Now I can set a due date by triggering this workflow transition. After I have set a due date, it will appear as a field in the edit screen.
For me it does the job, although it only allows to (initially) set a due date from the status "In Progress".
Note: There is no POST function to set a default value to the field Due Date. Only a few basic fields can be changed with a POST function.
Within the details view on the the boards, Description is in the "Description Area" which admins cannot add fields to. We can put fields in the "Primary Fields" section which are supposed to be always visible per the tooltip, but doesn't seem to be functioning properly for me. If you want an item to be visible only when populated it goes in the "Secondary Fields". So it looks like thought was given to this use case but lacking in proper implementation.
I perhaps think you are utilizing the New Issue View in JIRA Cloud? Which currently is still open and barely complete according to here: https://jira.atlassian.com/browse/JRACLOUD-70555
My guess is they are still working out the kinks on the New Issue View, since its mid-launch.
@[deleted] I am referring to our cloud instance and to the "Details View" in a board with the Jira Labs setting turned off. I appreciate the link as I mentioned this seemed new and this explains it. Interestingly I turned the Jira Labs setting back on which mucks with that view and the field appears. Looks like the current build isn't reverse compatible with the old details view and they broke it. It won't even show up if it's populated...
The problem with setting a default just so the field is visible is, from my experience, it never gets reset. Since it has a value nothing I'm aware of will make a user update the value. We did this at my first job with JIRA because management didn't like fields not showing. We ended up with more than half of the values as TBD for those fields when the issues were closed. This is a training issue.
I found the same in my arena Joe, I feel ya there. What we did was create custom series on individual reports and team reports that looked for tickets in a known status that should have the field value NOT be the default value, and then managed the misses that way if it returned a "closed" ticket where the custom field value was still set at the default value. This allowed individuals to view their personal report pages and easily see any misses they had. Leaders are also able to view their teams misses with only slight tweaks to the necessary JQL.
This will not make fields that initially have no value display, unfortunately. The only way to display a field is for it to have a value (without cracking code), so you will need to set a default value that is generic and then the field will display based on the settings you mention. As per the question, if the due date field has never been set, it will not display unless it has a value, which a person should just set the default value to something akin to "Required" or whatever and then it will display that. Custom fields with no default value, that have never been selected or given a value will not display without making changes to the actual code.
Documentation reads such that if in the Project settings for an Issue layout has the field in the "Primary" category it should always show up in the details view but based on my experience it doesn't function this way consistently. Making an optional field mandatory and populating with a default just to have it appear introduces risk that bad information could be passed to the team resulting in a loss of trust in the tools. Calling this a training issue oversimplifies what is a lack of consistency in admin controls that appear to have been planned for but not effectively implemented in the live version of this software. This should be considered a bug and be fixed not worked-around.
Hi community members, My name is Erika and I’m a product manager at Atlassian. We’re currently investigating how teams are planning work at the program level. We understand that every team in a tea...
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