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

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

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

Sounds like it is related to bug http://bugs.mantisbt.org/bug_view_page.php?bug_id=0004218

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

array
(
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).

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...

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.

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).