View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0023270||mantisbt||custom fields||public||2017-08-28 19:17||2017-09-09 18:15|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0023270: Restrict modifications of custom field type|
Having an existing custom field, with stored values, and later changing that custom field type to another different type, may end in errors when showing those values, or filtering on them.
So, we can consider some measures like:
|Tags||No tags attached.|
Easy and safe way:
In any other case, you would have to check first, if stored values can be converted.
BTW, there are also other changes possible so that existing values violate new rules, e.g. changes of possible values, regular expression, min. length and max. lenght.
Right. String should be an available fallback. So in that situations when there are incorrect values in the table, changing to string field type should allow the system to work at least without errors.
My main concern at the moment are errors that can't be managed at run time, and happens at database level.
A verification tool could be added later, that would scan current values to check compliance with datatype, and other logical constraints.
MantisBT: master 384f6ccf
Committer: dregad Details Diff
|Show a warning when changing field type
Show a warning when updating type for a custom field, for which already exists stored
Related issue: 0023270
|mod - core/custom_field_api.php||Diff File|
|mod - lang/strings_english.txt||Diff File|
|mod - manage_custom_field_update.php||Diff File|