An alternate approach to custom fields

[Myk Melez]

Sean McAfee wrote:

>Bradley Baetz <bbaetz at acm.org> wrote:
>  
>
>>On Fri, Mar 14, 2003 at 07:10:42PM -0500, Sean McAfee wrote:
>>    
>>
>>>For example, one of our workflows describes the testing path of individual
>>>returned parts.  Each part is run through a dozen or more tests.  The result
>>>of each test is recorded via a drop-down list on our current system's web
>>>interface.  Different tests are performed at different times.  Trying to
>>>squeeze all of this information into a single free-form text field and
>>>depending on users to keep the field formatted in a way that's suitable
>>>for querying seems like a recipe for disaster.
>>>      
>>>
>
>  
>
>>If the tests are just a pass/fail basis, then you could use keywords or
>>(in 2.17) bug flags to represent the various tests. If you sometimes run
>>tests more than once, then you'll have to use bug flags.
>>    
>>
>
>The keyword approach doesn't seem appropriate.  As I understand it, that
>would involve creating a trio of keywords (pass/fail/unknown) for each
>possible test, right?  But then there would be no way to prevent these
>keywords from being applied to inappropriate incidents, or to enforce
>exclusivity.
>
>I didn't know about bug flags, since I've been evaluating 2.16.2.  But I
>don't see any mention of them in the 2.17.3 documentation.  How do they
>work?
>  
>
Bug flags are a way to record the status of some characteristic of a bug 
whose status can be defined in a boolean fashion.  For example, bug 
fixes in the Bugzilla community must be approved by the module owner or 
his designee before they can be checked in.  The Bugzilla community uses 
an "approved" flag in their own Bugzilla installation 
(bugzilla.mozilla.org) to indicate whether or not a bug has been 
approved for check in.  A bug marked "approved+" has been approved for 
check in, while one marked "approved-" has been rejected.

Bug flags are configurable and product/component-specific, so you can 
add as many flags as you want and restrict them to certain products or 
product/component combinations.  The UI for setting flags on the bug 
report page consists of a table listing active flags and a pull-down 
menu showing their status.  To change a flag's status, users select a 
different status from the pull-down menu.  The options are "" (no value, 
a.k.a. flag not set), "+" (flag set positively), "-" (flag set negatively).

Flags are similar to trios of keywords in the functionality they provide 
but have the following advantages over keywords;

1. They can be made product/component-specific.
2. They provide a structured UI for making changes instead of making the 
user type magical values into an arbitrary text field.
3. They can be deactivated/reactivated without deleting records in the 
database, so you can remove a flag from the UI while still keeping the 
data around in case it becomes useful again.

Based on your description of the situation, I think bug flags are a good 
solution to your problem, with a few potential issues.  First, you 
mention that you need a way to prevent the values from being applied to 
inappropriate incidents.  Flags can be restricted by product/component 
combinations, so if your restrictions are all product/component-based, 
then this is not a problem.  Otherwise you would have to add 
functionality to flags to restrict them by your other criteria.  Second, 
flags do not enforce exclusivity, so this feature would have to be added.

If you are interested, I can give you administrator access to a test 
installation on the Bugzilla testing server 
(http://landfill.bugzilla.org/) so you can test flags and see if they 
would work for what you want to do.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030319/9327a5ef/attachment.html>