If you have the appropriate rights, adding a new custom field will be easy enough:
Different types of fields will be available:- integer (text field)
- string (text field)
- boolean (checkbox)
- formatted tring (wiki-style field) - see example above
- drop-down menu (combo box)
- select a position where to insert its custom field
- specify if the field is mandatory or not
- specify a default value
- list all of the possible values (in case of the drop-down menu)
With those example settings, the details tab of a bug would look like:
Note: this feature will be probably delivered through a commercial plugin (very cheap - around 30€ per user). It will be also delivered freely to all the users who have formerly (or are going to) contracted a support license.
1. For clarity, it will be useful to list the default fields too, since positioning rules in respect to these is not that clear.
ReplyDelete(These may be Grayed-out or partially editable - control of their position + see next item).
2. It might be helpful to add the ability of defining default value to existing fields - Mainly to formatted-string fields such as description (Enabling usage of common template), possibly also to Status, Severity etc.
3. Controlling the appearance of some of the less common default fields might also be useful, for instance: "Operating System" is not always required, and it's content is not always as needed.
4. Seems like not all items marked as Mandatory in custom fields above, appear as such at the bug dialogue image (may be just a snap shot issue)
5. Are combo values saved by their position in the list?
Can one later on rename combo selection items and this will affect all past entries?
What will be presented if one mistakenly deleted an entry which was already been used? (this might happen in upgrades etc. too)
6. Not sure if there is any demand for Multilingual (Locale) values in custom fields, but that should be considered, as some international companies might be working across different languages.
7. I hope one can backup the custom fields settings in XML format or etc.
8. Will it be possible to pass custom field values to Launchers?,
control their appearance in Report documents?
Will the custom fields be available when connecting to external bug tracking tools?
ReplyDeleteWill it be possible to map dedicated external tools fields to the custom fields?
1. This is something that has been considered but it finally has been postponed to next version because of a very high "complexity/benefit" ratio.
ReplyDelete2. Default values are defined for custom fields but not for standard fields. Although this is a good idea to do so, this will require a different implementation. So technically it is a different feature. Added in the TODO list
3. The custom fields can be configured as mandatory or not.
4. Yes probably just a snapshot issue. Will check this...
5. Yes, items are displayed in the combo-boxes as listed in the "possible values" field.
6. I don't think this is necessary at this point. Added in the TODO list though.
7. No, this has not been developed. This is probably not something people will have to do often I guess.
8. No. Attributes and params are passed to the launchers but none of the standard fields are passed through (apart the name and the index) so I don't see any need to pass the custom ones more than the standard ones. But if there are some use cases, this could be revised.
No, the custom fields for the bugs are available only to the integrated bug tracking module. If you're using an external bug-tracking such as Mantis, JIRA, Trac or Bugzilla, this will need to be managed from the bug-tracking system.
ReplyDeleteSeems like you misunderstood item:
ReplyDelete3. Controlling the appearance of some of the less common default fields might also be useful, for instance: "Operating System" is not always required, and it's content is not always as needed.
I was referring to currently available "Default" fields and not the "custom" ones.
Which one might prefer not to see, and/or prefer to set their own values.
For one to replace such field with a Custom field, he needs to hide the default field.
The standard fields include too much "logic" to be easily removed at this point. The customization is a wide area to work on. What is in the 1.5 is the very first step of a long march ;)
ReplyDelete