The custom field with the type *Date of First Response* is clearly a date-time range picker, so why is it matching the format of a date range picker instead? When using this custom field, an issue occurs.
Thanks for the screenshots. I can see that Jira is throwing an error because the date/time value being supplied is not what it is expecting in this case. It looks like your system is trying to supply a date value in the format of
dd/MM/yyyy
and Jira is telling us that it was instead expecting
d/MMM/yy
I'd be interested to try to learn more about your environment. Could you let me know what settings you see within Settings > Look and feel. Specifically in the Date / time formats. In my own environment I have customized this slightly to always use 4 digit years such as
That would be the first place I would check. But there is also another concern about how Jira is trying to store dates. Have you customized the Settings > General Configuration > Advanced Settings that control Jira's date/time values? Again I have done this in my own cloud site, but this was only to force Jira to use 4 digit years.
Hi @Andy Heinzer Thank you for your response.
The two settings you mentioned are both using the default values, with no special configurations applied.
Settings > General Configuration > Advanced Settings
Settings > Look and feel
Steps to reproduce the issue:
1.Create a new custom field with the type 'Date of First Response.'
Settings > Issues > Custom fields
In the field's edit section, you can see that the search template only allows the date range picker to be selected.
2.Set this field as required.
project > issue > Configure
You can add a custom field that you've created or directly use the system's default 'Date of First Response' field.
3.Then, when go back to the issue to set the value for this field, will encounter an error.
I believe the cause of this error is that the 'Date of First Response' defined in Jira is a date-time range picker, but it’s being matched with the date range picker format.
Look forward to your further response on this issue. Thank you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
ah that explains it. Setting the field as required will force the Jira issue to always have a value for that field. When I say always, I mean throughout the lifecycle of an issue in Jira, from creation, all the way through any transitions and any edits.
But that isn't just a typical custom field. It's actually a calculated custom field. It's specifically designed to have Jira automatically populate a value to that field based on a date/time value when the first person (that is not the reporter) responds to the issue in a comment. By design that field should be null when an issue is created. But because the field configuration scheme sets it to required, this configuration is effectively circumventing the intended function of that field.
I have the suspicion that if you mark the field as optional instead, this problem won't appear at all. In turn that's also what I recommend moving forward here.
If this is still happening after the field is not marked as required, then I'd want to know more about what value you have set for Language and Timezone on the page https://id.atlassian.com/manage-profile/account-preferences as this might be a factor in regards to how dates/times are being entered based on the individual user's settings.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Andy Heinzer Thank you for your explanation!
If this field is set as required, how can I avoid error when creating an issue using the Jira REST API? How can I determine which specific fields should have a default value of null?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That field should not be set as required though. To do so short-circuit's the intended design of that custom field (Date of First Response). Because you would have to give it a value when the issue is created if the field is required.
The description on that field type states:
The date of the first comment on an issue by anyone who is not the issue's reporter
Since the issue has to be created before a comment can be left on it, that field should never be required in the field configuration. Otherwise, you would have to give it a date value that would not be accurate.
Perhaps instead you could use a workflow validator to require the field have some value after the create transition. This way you could still force end users to have a value in the field, but not via the field configuration scheme which would enforce a value on that field at the time of issue creation.
How can I determine which specific fields should have a default value of null?
Any field in Jira that doesn't have a value is considered null. Only required fields in the field configuration scheme will force a value to the field at all times.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jira user(public) , welcome to the Atlassian Community and thanks for your post.
I have tagged Atlassian into this post so hopefully they can take a look and give us a hand.
Cheers!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Jira user(public) , apologies for the delay. I just wrote in our Slack as well to see if someone can help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.