View Issue Details

IDProjectCategoryView StatusLast Update
0003791mantisbtcustom fieldspublic2005-04-18 10:29
ReporterRJelinek Assigned Tovboctor  
Status closedResolutionfixed 
Fixed in Version1.0.0a1 
Summary0003791: Additional Custom-Field-Type "version"

It would be useful, to define a new custom-field-type that shows all versions defined for a project. So I can easily realize a "fixed in version"-field.

TagsNo tags attached.


related to 0005180 closedvboctor Support custom fields with dynamic possible values 
has duplicate 0004359 closedthraxisp From where comes the list box of product version 




2004-06-21 17:18

manager   ~0005752

The "fixed in version" field is now implemented as a standard field in the CVS. This will be included in 0.19.0.



2004-07-18 07:13

manager   ~0006114

Last edited: 2004-07-18 07:13

Although "fixed in version" field was added, it is still useful to implement this feature (eventually). The idea is that users may want to add custom fields which are pre-populated by release versions. These will introduce three kinds of custom fields given the modifications in 0.19.0a2:

  • released versions
  • future versions
  • all versions

edited on: 07-18-04 07:13



2004-08-11 14:36

reporter   ~0006944

I'd like to suggest this for 0.19.1. I can code it.



2004-08-12 07:30

reporter   ~0006964

Sounds like it is related to bug



2004-08-14 17:32

manager   ~0006990

What about having a custom function that takes the name of a custom field and returns an array as follows:

array( 'id' => 'blah', 'label' => 'blah blah' ),
array( 'id' => 'blah2', 'label' => 'blah blah 2' ),
array( 'id' => 'blah3', 'label' => 'blah blah 3' ),

This can be called for enumeration / checkbox custom fields with "possible values" empty (details to be decided).

Implementing the above will allow us to provide the flexibility to administrators to support any intelligent type of custom field that depends on information extracted from Mantis (eg: version) or extended from elsewhere (eg: their ldap, filing system, or whatever).



2004-08-16 13:01

reporter   ~0007018

Think i'll agree with victor on this one. For a 'type' of custom field, e.g. checkbox, drop down, listbox - we've pretty much implemented those already.

Only thing that i don't think is covered atm is a 'textarea' type field. Other then that the other requests have been for things like users, versions, http links - while http links could arguably be it's own field type, things like users/versions might be better based on a custom function.

If we did go down this route (and provided some default custom functions with mantis), how would be define + allow a user a pick a predefined custom function e.g. version list. ?
Ideally, they should be able to choose themselves to use enum/checkbox/drop down list etc...



2004-08-16 13:39

reporter   ~0007019

The version list is slightly different in that it needs to be tied into other code. For example, if the project admin changes version 2.0 to 1.99 it gets reflected in the "fixed_in_version" fields, and needs to be propagated into the custom field as well.

One approach would be to add a "default" hook to the processing to allow a user to implement their own custom_functions for this.



2005-01-29 09:03

manager   ~0009145

As part of 0005180, this is now implemented. In possible values, the user can type "=categories", "=versions", "=future_versions", "=released_versions" (without the double quotes). The field will be populated as expected, based on the current project. The user can still decide separately on the type of custom field to be shown to the user (listbox, checkboxes, ...etc).

Issue History

Date Modified Username Field Change
2004-04-29 14:33 RJelinek New Issue
2004-06-21 17:18 vboctor Note Added: 0005752
2004-06-21 17:18 vboctor Category bugtracker => custom fields
2004-07-18 07:13 vboctor Note Added: 0006114
2004-07-18 07:13 vboctor Note Edited: 0006114
2004-08-11 14:36 thraxisp Note Added: 0006944
2004-08-12 07:30 DGtlRift Note Added: 0006964
2004-08-14 17:32 vboctor Note Added: 0006990
2004-08-16 13:01 grangeway Note Added: 0007018
2004-08-16 13:39 thraxisp Note Added: 0007019
2004-08-19 12:04 thraxisp Relationship added has duplicate 0004359
2005-01-29 09:03 vboctor Status new => resolved
2005-01-29 09:03 vboctor Fixed in Version => 0.19.3
2005-01-29 09:03 vboctor Resolution open => fixed
2005-01-29 09:03 vboctor Assigned To => vboctor
2005-01-29 09:03 vboctor Note Added: 0009145
2005-01-29 09:04 vboctor Relationship added related to 0005180
2005-04-18 10:29 vboctor Status resolved => closed