View Issue Details

IDProjectCategoryView StatusLast Update
0023270mantisbtcustom fieldspublic2017-09-09 18:15
ReportercproensaAssigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version2.6.0 
Target VersionFixed in Version 
Summary0023270: Restrict modifications of custom field type
Description

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.
An example of this:
Having a field of type string, with literal values already stored for issues, and later changing for numeric type, gives incoherent results, and can lead to errors if filter or sorting is based on the datatype.
Another example: If changing string to type date, an error occurs, calling date() with a string parameter
etc.

So, we can consider some measures like:

  • Don't allow to change a string based type into a numeric type, when there's already stored values. Or possibly not between any type?
  • Show a warning in custom field manage page if there are stored values incoherent with current type.
TagsNo tags attached.

Activities

atrol

atrol

2017-08-29 03:23

developer   ~0057559

Easy and safe way:
If there are stored values, allow just changing type to string.
Don't allow any other type change.

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.

cproensa

cproensa

2017-08-29 04:09

developer   ~0057560

If there are stored values, allow just changing type to string.

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.

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.

My main concern at the moment are errors that can't be managed at run time, and happens at database level.
For example, by having all the values stored as srting db fields, we must cast to numbers if we want filters to sort them numerically, and this fails if there is invalid data.

A verification tool could be added later, that would scan current values to check compliance with datatype, and other logical constraints.

Related Changesets

MantisBT: master 384f6ccf

2017-08-31 06:50:21

cproensa


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
values.

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

Issue History

Date Modified Username Field Change
2017-08-28 19:17 cproensa New Issue
2017-08-29 03:23 atrol Note Added: 0057559
2017-08-29 04:09 cproensa Note Added: 0057560
2017-09-09 18:15 dregad Changeset attached => MantisBT master 384f6ccf