View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003791 | mantisbt | custom fields | public | 2004-04-29 14:33 | 2005-04-18 10:29 |
Reporter | RJelinek | Assigned To | vboctor | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 1.0.0a1 | ||||
Summary | 0003791: Additional Custom-Field-Type "version" | ||||
Description | 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. | ||||
Tags | No tags attached. | ||||
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:
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 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. ? |
|
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). |
|