Follow-up to #14, which deliberately scoped the new "Date and time" custom field format to issue custom fields.
Redmine supports date custom fields on several customized types, and each is a separate CustomField subclass with its own admin tab:
ProjectCustomFieldVersionCustomFieldUserCustomField / GroupCustomFieldTimeEntryCustomFieldIssueCategoryCustomField, DocumentCategoryCustomField, and the enumeration ones
What needs checking
The format itself is type-agnostic, so most of the work is verification rather than new code:
- Which subclasses actually offer
date today, since the format list per type is filtered by CustomField#format_supported?-style logic and each subclass declares what it allows.
- Whether anything in the format assumes an issue.
cast_single_value and formatted_value take customized, and the current implementation ignores it, which is a good sign.
- Time entries are the interesting case: they already carry a
spent_on date, so a datetime custom field there may overlap with what the core model means. Worth deciding rather than enabling by default.
- Filtering and grouping should be re-checked per type, since each type's query class differs.
Why it was left out
Scoping the first change to issues kept it verifiable end to end in one pass, and issues are where the demand came from. Widening is cheap to do and cheap to test once the format itself is settled.
Follow-up to #14, which deliberately scoped the new "Date and time" custom field format to issue custom fields.
Redmine supports date custom fields on several customized types, and each is a separate
CustomFieldsubclass with its own admin tab:ProjectCustomFieldVersionCustomFieldUserCustomField/GroupCustomFieldTimeEntryCustomFieldIssueCategoryCustomField,DocumentCategoryCustomField, and the enumeration onesWhat needs checking
The format itself is type-agnostic, so most of the work is verification rather than new code:
datetoday, since the format list per type is filtered byCustomField#format_supported?-style logic and each subclass declares what it allows.cast_single_valueandformatted_valuetakecustomized, and the current implementation ignores it, which is a good sign.spent_ondate, so a datetime custom field there may overlap with what the core model means. Worth deciding rather than enabling by default.Why it was left out
Scoping the first change to issues kept it verifiable end to end in one pass, and issues are where the demand came from. Widening is cheap to do and cheap to test once the format itself is settled.