View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0012602 | mantisbt | custom fields | public | 2010-12-11 08:22 | 2021-01-23 05:26 |
Reporter | babasss | Assigned To | vboctor | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.3 | ||||
Target Version | 2.9.0 | Fixed in Version | 2.9.0 | ||
Summary | 0012602: Default value for a date don't work | ||||
Description | 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 |
=> The custom date will not be filled | ||||
Additional Information | the bug is corrected with this modification : to : | ||||
Tags | No tags attached. | ||||
has duplicate | 0019485 | closed | dregad | Custom field default date can not be displayed {today}, In addition to the issue of report issue status |
related to | 0019482 | closed | vboctor | Using custom fields (date) with default value and required on resolve displays an error |
related to | 0023594 | closed | vboctor | Reporting an issue with default date {now} that is not visible doesn't work |
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) core/custom_field_api.php Modified: |
|
I had a short look at the source. It seems that the current behavior is the intended one. 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) |
|
You're right, that makes sense The use case I have is a bit peculiar though: 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 Note: Of course, default value should never be applied when a user value already exists |
|
In addition, depending on error reporting settings, a warning will be triggered (as described in 0019482) |
|
The following issues were fixed:
|
|