View Issue Details

IDProjectCategoryView StatusLast Update
0005636mantisbtcustom fieldspublic2017-06-13 05:51
ReporterLXS Assigned To 
Status newResolutionopen 
Summary0005636: Store custom fields ids, not their values.

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>

TagsNo tags attached.


related to 0007549 new Unable to localize string values of a custom field of type enumeration 
related to 0020305 new Create localization framework for user created objects 
child of 0005650 acknowledged Investigate/Implement Enhanced Custom Field support 




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.

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.