0016433: History should store custom fields as ID not name

ID	Project	Category	View Status	Date Submitted	Last Update
0016433	mantisbt	custom fields	public	2013-10-01 05:19	2014-09-22 18:51

Reporter	dregad	Assigned To
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	new	Resolution	open
Product Version	1.2.15

Summary	0016433: History should store custom fields as ID not name
Description	This is a follow up on the fix for 0014650 applied to the master branch, which removes truncation of custom field name in the history table. Grangeway pointed out that it would be better to store the custom field ID instead, "such that if a custom field gets renamed, or two custom fields have the same name, the history table gets linked to the correct custom field."
Tags	No tags attached.

dregad 2013-10-01 05:21 developer ~0038168	Fixing this requires a revised update_history_long_custom_fields() helper function, or an extra schema update step. One catch: properly handle existing history entries when a custom field gets deleted (replace ID by name in this case ?). Need to check how this situation is handled today.

nimmich 2013-10-03 13:46 reporter ~0038189	IMHO histories should always be denormalized and represent the values that were valid at the time of writing. It was correct then, wasn't it? Anyway, you don't get headaches with deleted custom fields and other anomalies and can always print what is there without any hassle.

dregad 2013-10-04 04:32 developer ~0038201	IMHO histories should always be denormalized and represent the values that were valid at the time of writing That's one way to see things. However in the case of custom fields, you have to consider the fact that they are by nature more volatile than the rest of the info which is logged in the history, not to mention the case of localization - storing the id would allow display the translated field name instead of a "technical" name which can potentially be quite different from what the user sees.

nimmich 2013-10-06 10:49 reporter ~0038213	From what I remember of the localization framework in Mantis it depends on the strings not on the ids what is displayed. And you could display different information if the name changed which wouldn't be possible otherwise because the id is the same.