0005636: Store custom fields ids, not their values. - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0005636	mantisbt	custom fields	public	2005-05-23 10:01	2017-06-13 05:51

Reporter	LXS	Assigned To
Priority	normal	Severity	feature	Reproducibility	always
Status	new	Resolution	open

Summary	0005636: Store custom fields ids, not their values.
Description	When using custom fields, Mantis store their actual values in the database as-is. ie: A custom field "Type" returning "Bug\|Enhancement\|Support", through a custom function or not, will only permit to store values like "Bug", "Enhancement" and "Support". When internationalizing everything, this way of thinking is not efficient because values are stored depending on the language used to define the custom field. In french per example, Enhancement is "Evolution". And if our custom function store "Evolution" as "Type" value, we'll have both "Evolution" and "Enhancement" for the field "Type", which is pointless. What I was thinking is to consider a custom field like severity. ie: the possibility to store its content like "0:universal_label_1,10:universal_label_2,etc...". Then we would modify option lists "value" attribute according the first value. The resulting code would be like: <select name="custom_field_xx"> <option value="0">lang_getted_universal_label_1</option> <option value="10">lang_getted_universal_label_2</option> and so on...instead of <select name="custom_field_xx"> <option value="universal_label_1">universal_label_1</option> <option value="universal_label_2">universal_label_2</option>
Tags	No tags attached.

daryn 2007-06-05 17:16 reporter ~0014682	Would it be possible to make this a configurable option for each custom field? I have a case for a user custom field named department. When a user logs time in an issue, I want to know what department they were in when the time was logged. If the user changes departments, the value in the dept custom field would be changed to reflect their new department. If just the user id is stored, then the time tracking data is skewed for all issues that reference that user. However, if the department value is stored in the issue along with the user id, the data remains valid. So, in most cases I think storing the id is preferable, but it would be nice to have a choice. If someone has a better solution I'd like to hear it.

kjell.rilbe@datadia.se 2014-03-05 02:45 reporter ~0039619	This one gets a strong upvote from me. It kinda makes custom enum fields useless without it. :-( I'd also like to be able to create a custom enum field that uses an already existsing enum, e.g. priority. I was expecting to be able to do that by entering the consts for that enum as possible values, i.e. "NONE\|LOW\|NORMAL\|HIGH\|URGENT\|IMMEDIATE", but it obviously doesn't work. Probably better to be able to specify the possible values in the "int:text,int:text..." format already suggested, but perhaps in addition be able to say "This custom field should have the same value type and value set as the field X, where X could be "priority" for example.