View Issue Details

IDProjectCategoryView StatusLast Update
0004640mantisbtcustom fieldspublic2017-05-17 14:19
Reportertandler Assigned To 
Status newResolutionopen 
Product Version0.19.0 
Summary0004640: New custom field types: "Version", "User"

I'd suggest to add two new custom field types: "Version", "User".

"Version": The field contains a version number

For example, we defined a field "target version" to aid planning in which version this issue should be fixed. It would be cool to be able to refer to the versions managed by Mantis, e.g. to aid renaming of versions etc.

"User": The field contains a user ID

For instance, if you want to add a QA responsible or other roles involved in this issue.

Additional Information

Once you have the "User" Type for custom fields, my next feature request will be to be able to include the custom field name in the "Assign To:" popup in the bug view page, e.g. Assign to:
[QA responsible] -- if such a custom field is used for this project

TagsNo tags attached.


related to 0005180 closedvboctor Support custom fields with dynamic possible values 
related to 0003790 acknowledged Additional Custom-Field-Type "users" 
related to 0014565 confirmed New Custom field User 




2005-01-29 08:48

manager   ~0009142

Support for fields like categories and versions is done as part of 0005180. However, fields like users are not supported yet. The reason is that for users you will want to display the user name, but actually store a different value which is the user id.



2006-04-19 07:47

reporter   ~0012621

It's great that much of this is already resolved (0005180), thanks for implementing this!

I now experienced a problem with our "target version" field:

  • our "target version" is defined as "=future_versions".
  • once a version is now released, we cannot filter for all issues with this target version anymore, as the value disappears from the list
  • for filtering, it would be very helpful to be able to filter for multiple values (e.g. 1.6.1, 1.6.2, or 1.6.* with wildcards), but when assigning values, ony one version can be selected. Maybe, you need to ba able to define different things for the "edit" and "filter" UI?
  • it also would be nice to be able to get a list (when selecting a filter) with only the values used in the DB. (This would of course require a different definition of the custom field function for the filter UI.)
    Any suggestions?


2006-08-02 12:07

reporter   ~0013180

Last edited: 2006-08-02 12:08

If you prefere to have an incomplete solution for the "users custom field issue" (one that simply stores the username as string, igoring deletions and renamings) over having no solution, you can place the following in your custom_functions_inc.php, that gives you "=users" and "=developers" as possible enumeration-values



# Construct an enumeration for all usernames.
# To use this in a custom field type &quot;=users&quot; in the possible values field.
function custom_function_override_enum_users() {

    $t_users = project_get_all_user_rows( helper_get_current_project(), ANYBODY );

    $t_enum = array();
    foreach ( $t_users as $t_user ) {
        $t_enum[] = $t_user['username'];
    sort( $t_enum );
    $t_possible_values = implode( '|', $t_enum );

    return $t_possible_values;
# --------------------
# Construct an enumeration for all usernames.
# To use this in a custom field type &quot;=developers&quot; in the possible values field.
function custom_function_override_enum_developers() {

    $t_users = project_get_all_user_rows( helper_get_current_project(), DEVELOPER ); 

    $t_enum = array();
    foreach ( $t_users as $t_user ) {
        $t_enum[] = $t_user['username'];
    sort( $t_enum );
    $t_possible_values = implode( '|', $t_enum );

    return $t_possible_values;




2006-08-02 12:08

reporter   ~0013181

I just noticed the "=versions" features is not documented (except in the source). Or did I overlook something?



2006-09-14 03:53

reporter   ~0013377

I would like to add customfields which contain user names as well. In my point of view, it is OK to just store the string representation (user name) in stead of the ID (user ID). As long as the value that is selected from the field should be an existing username.



2007-10-20 08:12

reporter   ~0015919

Last edited: 2007-10-20 11:51

added an implementation on note in 0003790



2009-01-29 22:52

reporter   ~0020741

Just wanted to point out that a complete solution that stores user IDs and includes a definable user level threshold is now available in 0003790. Hope this helps!

Issue History

Date Modified Username Field Change
2004-09-29 14:56 tandler New Issue
2005-01-29 08:46 vboctor Relationship added related to 0005180
2005-01-29 08:48 vboctor Note Added: 0009142
2006-04-19 07:47 tandler Note Added: 0012621
2006-08-02 12:07 polzin Note Added: 0013180
2006-08-02 12:08 polzin Note Edited: 0013180
2006-08-02 12:08 polzin Note Added: 0013181
2006-09-14 03:53 ericzuur Note Added: 0013377
2007-10-20 08:12 qips Note Added: 0015919
2007-10-20 11:51 vboctor Relationship added related to 0003790
2007-10-20 11:51 vboctor Note Edited: 0015919
2009-01-29 22:52 djcarr Note Added: 0020741
2012-08-25 13:03 atrol Relationship added related to 0014565