View Issue Details

IDProjectCategoryView StatusLast Update
0005636mantisbtcustom fieldspublic2017-06-13 05:51
ReporterLXS Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Summary0005636: 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>

TagsNo tags attached.

Relationships

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 Enchanced Custom Field support 

Activities

daryn

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

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.

Issue History

Date Modified Username Field Change
2005-05-23 10:01 LXS New Issue
2005-05-25 17:39 grangeway Relationship added child of 0005650
2007-06-05 17:16 daryn Note Added: 0014682
2014-03-05 02:45 kjell.rilbe@datadia.se Note Added: 0039619
2017-01-18 10:19 atrol Severity major => feature
2017-06-08 10:46 atrol Relationship added related to 0007549
2017-06-08 10:46 atrol Relationship added related to 0020305