View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004640 | mantisbt | custom fields | public | 2004-09-29 14:56 | 2017-05-17 14:19 |
Reporter | tandler | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 0.19.0 | ||||
Summary | 0004640: New custom field types: "Version", "User" | ||||
Description | 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: | ||||
Tags | No tags attached. | ||||
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. |
|
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:
|
|
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 <pre> --------------------
</pre> |
|
I just noticed the "=versions" features is not documented (except in the source). Or did I overlook something? |
|
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. |
|
added an implementation on note in 0003790 |
|
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! |
|