An alternate approach to custom fields

[Jon Wilmoth]

I'm interested in custom fields and was under the impression the patch was "almost there"!  While I think the flags are a good thing, my situation requires non-boolean values and disparate groups of information (i.e. what project the issue/bug is for AS WELL as what internal business unit(s) the issue impacts).  My timeframe is relatively small for implementing this functionality, so I'd like to offer my assistance on finalizing the custom fields approach immediately.

-----Original Message-----
From: Myk Melez [mailto:myk at mozilla.org] 
Sent: Wednesday, March 19, 2003 6:01 AM
To: Sean McAfee
Cc: developers at bugzilla.org
Subject: Re: An alternate approach to custom fields

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