So I have a custom field, lets call it: "Color"
- I have it set up as an enumerated list, lets say 'Green', 'red', gold', 'black' below it ('Green' is the default, although of course there is no actual default entered in the custom list field, since it makes no difference anyway, since the top value is always the default regardless of that setting, but thats a different bug...)
- I have it set to display this field when updating or resolving a bug since there might be additional modifications of this data to enter at this point.
It should list whatever was set in the last instance, but instead it reverts all the data to the "defaults" each time it is called from an update or status change form, and then commits those defaults, as if they were new data, to the database, wiping out your original data.
So if you set the field to lets say 'red' and then commit the data, okay its fine there as expected, but then if you go to "update information" or a status change form where the custom field is told to be in, it presents you with the feilds again but with the default set to 'Green' again and it will commit these defaults unless the settings are changed to match the current state, so it destroys your data by default.
The only way around this is to acrtively keep setting it to match the intended value, but only if you happened to write down what the data was, since you cannot see the field's 'current' data from within the form where it is now being changed.
Its also strange to see that the bug history shows how the field was "changed" from: Green => Green ; it would seem that globally such an event shoudlnt occur to be recorded here at all unless there were some actual change that occurred. Maybe this uncovers a deeper bug than this.
Any ideas how to fix this one?
Custom fields: enumerated list data is not persistent
Moderators: Developer, Contributor