View Issue Details

IDProjectCategoryView StatusLast Update
0012602mantisbtcustom fieldspublic2017-12-04 02:17
Reporterbabasss Assigned Tovboctor  
Status closedResolutionfixed 
Product Version1.2.3 
Target Version2.9.0Fixed in Version2.9.0 
Summary0012602: Default value for a date don't work

When you use a custom field date with a default value. If the field is not filled on the report bug page, when you update the bug, the default value date is not filled

Steps To Reproduce
  • Create a custom field date with a default value
  • Check only "Display When Updating Issues"
  • Create a new bug
  • Update it

=> The custom date will not be filled

Additional Information

the bug is corrected with this modification :
In custom_field_api.php on line 1414 (function print_custom_field_input) :
change :
if( $t_custom_field_value === null &&
( $p_field_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_LIST || $p_field_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_RADIO ) ) {

to :
if( $t_custom_field_value === null &&
( $p_field_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_RADIO ||
$p_field_def['default_value'] !== null ) || $t_custom_field_value == null ) {

TagsNo tags attached.


has duplicate 0019485 closeddregad Custom field default date can not be displayed {today}, In addition to the issue of report issue status 
related to 0019482 closedvboctor Using custom fields (date) with default value and required on resolve displays an error 
related to 0023594 closedvboctor Reporting an issue with default date {now} that is not visible doesn't work 




2014-07-24 12:53

reporter   ~0040970

Last edited: 2014-07-24 12:57

Still present in 1.2.16 (maybe 1.2.17)

"print_custom_field_input()" does not list CUSTOM_FIELD_TYPE_DATE as a type getting a default value when modifying a bug (only when creating a new one).

Patch as below (or delete the type test altogether if this applies to every type)

Line 1350:
if( $t_custom_field_value === null &&
( $p_field_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_RADIO) ) {

if( $t_custom_field_value === null &&
( $p_field_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_RADIO ||
$p_field_def['type'] == CUSTOM_FIELD_TYPE_DATE) ) {



2014-07-24 14:40

developer   ~0040971

I had a short look at the source. It seems that the current behavior is the intended one.
The default value should only be used when creating a new issue.

E.g. wouldn't it be quite confusing if you click on "Edit" button just to change priority of the issue, click "Update information" and get also some other values changed?

The implementation for the other types is just because null values don't make sense (e.g. radio means that one option must be selected)
See comment in source :

If the custom field value is undefined and the field cannot hold a null value



2014-07-24 15:01

reporter   ~0040973

You're right, that makes sense

The use case I have is a bit peculiar though:
-I use two "resolved_date" and "closed_date" custom fields that are required for resolution and close (respectively), and only shown on the "change status" screen
-As the user clicks "Change status" with one of those status selected, I expected the field to show (which it does) with the default value (set as {today})

Following this, and taking into account your input, maybe the default value should be applied whenever the field is required, rather than when its type make it non-nullable
Works for my use-case, and works for the simple modifying use-case too: one can either make the field non-required, and keep the same behavior as today, or set the custom field as "required for modify", and have the default value applied (if any)

Note: Of course, default value should never be applied when a user value already exists



2015-03-12 04:23

developer   ~0049188

In addition, depending on error reporting settings, a warning will be triggered (as described in 0019482)



2017-11-09 22:57

manager   ~0058172

The following issues were fixed:

  • Use of default values for custom fields of type was date was not working, e.g. {now}, {+2 days}, etc.
  • For issues that were submitted with invalid value for custom field, the issue was not viewable, currently it is viewable with empty date field.