Get 24/7 customer support

Kirill Bondar  Staff  1/5/2010 1:07:09 PM

Suppose, we'll allow marking Due Date, Estimates and Custom Fields as required - other fields always assigned the values as specified in project defaults.

What if the person opening the issue does not have, or has read only access to the field? Should the field contain blank value in this case or should it be initialized with some default value? What would be default value for, say, Due Date then?

Earl Griffin 1/5/2010 2:00:34 PM

Always assigning values as specified in project defaults is not a good idea, for example, the Version option can have more than one valid selection if you have products that are in maintenence mode for customers and are on different versions (code branches). The most accurate way to handle this issue (as far as I can determine) is to allow making it a required field and have the default as blank, so that the user must select something for the field before the issue can be saved.

If a person opening an issue has only read access to a required field, then the admin has to evaluate if that field should really be required or if the person should in fact have write access to the field. If it is a valid condition to have a required field that some Roles have only read access then you would have to implement a condition where depending on the Role of the "Assigned to" that Role would support configurable Required field settings.

For example:
Role (Tester): "Due Date", not required filed, and unavailable
Role (Programmer): "Due Date", not required field, and available
Role (Manager): "Due Date", Required Field, and available

This is just an example and of course if you analyze this you will note that this raises another problem with BUGtrack, there is no real concept of workflow and requirements for each step of that workflow. Not all issues follow the same workflow. Issues submitted by a customer do follow a different workflow than an issue submitted by a tester during product development.

Kirill Bondar  Staff  1/6/2010 9:28:22 AM

Technically it would not be hard to add "required" check to the new/edit issue form - we have all necessary code ready.

The idea behind defaults is to streamline new issues creation - ideally, when project defaults set to right values, in most cases the user should only fill the issue title and type the description. As with software projects - in most cases you'll report a defect in the product version currently in development. There is a number of feature requests for future versions or critical issues reported for the version already released but this number is relatively low comparing to a number or defects.

To support required for custom fields we should probably first solve another problem - to allow controlling the appearance of the custom field in the select list of operations. Some custom fields, say Platform, are not relevant when closing the bug, some are not relevant on opening stage. Adding "required" flags to the custom fields in their current form will handle issue opening case but won't handle the others.

Earl Griffin 1/6/2010 11:29:44 AM

I agree, controlling the appearance of the custome field is important. In many cases a specific filed should only be required if another field has a specific setting. For example we want to use the Categories field to specify if the issue is "Internally Reported" or "Customer Reported". In this case the Categories field must be a required field with the default being set to blank so that the person opening the issue has to intentionally set it. If the Categories field is set to "Customer Reported" then another field Customer Issue Number needs to become a required field. If Categories is set to "Internally Reported" then the Customer Issue Number field is not a required field.

The above example is probably one of the most important examples for a software company. The metric "Customer Reported" issue versus "Internally Reported" issues versus total number of issues is an extremly important metric to gage testing affectiveness.