New custom fields proposal
JWilmoth at starbucks.com
Thu Apr 10 19:05:17 UTC 2003
From: Sean McAfee [mailto:etzwane at schwag.org]
Sent: Wednesday, April 09, 2003 6:13 PM
To: developers at bugzilla.org
Subject: Re: New custom fields proposal
"Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
>Currently, Bugzilla offers a fixed number of named fields to describe
>bugs. These fields are shared across every component in the system.
>The proposed additional functionalty is the ability to define
>additional fields on a per-component basis. These additional fields
>are called "custom fields".
>I assume your talking about "component" being a broad system module
>(i.e. search, creation, reporting, etc.). I'd suggest you use a
>different term so as not to be confused with a Product component.
Er, no, actually. I did mean "component" in the "Product component"
I think component specific custom fields might be valuable in the future
however I agree with the statement there are serious cons with that
approach. I'd stick with per product and global.
>A selection field takes its value from a set of distinct string
>values. No string value in any selection field's set of valid values
>may contain vertical whitespace, contain leading or trailing
>whitespace, or exceed 255 characters in length.
>[Open question: Should there be a limit on the size of the set of
>valid strings? If so, should this limit be global or per-component?]
>The main issue here is screen real-estate which is a global issue.
>Having unlimited select lists can throw the html tables out of wack.
>I'd suggest a global limit set to the largest possible value for the UI
>where custom fields will be added.
I was talking about the total number of selections allowed in a single
selection field, whereas you seem to be referring to the maximum
length of a single selection field. I wouldn't mind chopping displayed
selection values at some reasonable length limit, but in that case the
interface should probably display a warning if an attempt is made to
selection values which exceed this limit.
Agreed, admins will need to know a max length. I would suggest
restricting admins from violating the max length rather than warning and
truncating. Also I don't think the system should impose a constraint on
the number of values available. Certainly there are usability issues
when a list gets too long, but let's make the Bugzilla administrators
accountable for some common sense things.
>Different components may define different custom fields with the same
>name. Therefore, custom field form elements for custom fields
>belonging to the same component will need to be grouped together,
>clearly labelled as belonging to that component.
>I'd like to see two levels of scoping global and by product for custom
>fields. Anything else is gravy.
Is it normal that a Bugzilla installation will want to define some
information that applies to *every* product?
In my experience yes. We may have a "need by date" that all dev teams
use, but certain products may have special "value add" fields like test
lab location or bandwidth elements that don't apply to other products.
>Security - Assign access to custom fields to groups. Assignment would
>hide fields from being displayed.
>Validation - Required vs. not required. In addition to the type
>checking described above, a required flag should be included in the
>definition of the field.
I thought of including this, as TeamTrack offers it, but there a field's
"required" status is based on an incident's state within its enclosing
project's workflow. Bugzilla doesn't offer a similar state-dependent
(as far as I know). Do you mean that a "required" field would be
only when a bug is first created?
I agree that often there is more value in state-aware constraints than
not. For simplicity sake, my suggestion would be to do a first cut of
either required or not...no state considerations. If this is
toggleable, admins can select values appropriate to their "typical
>Presentation - Error messages, Labels and references to the custom
>names (i.e. contextual help pages) should allow for the displaying of a
>system admin controlled term.
I'm not sure I understand. Can you provide some examples?
Let's say I add a "NeedBy" field, the field may have a systematic name
or identifier and it will should have a user-friendly name "i.e. "Need
By Date". The label next to the field, any popup error msgs etc. should
use the text "Need By Date" rather than "NeedBy" or "customField4".
>Consistency - It would be nice to have a uniform approach to field
>definitions (security, validation, and presentation) for both stock and
>custom fields alike.
I agree that it would be nice--very nice, even--but I'd prefer to keep
custom fields orthogonal and avoid modifying Bugzilla's core. We'll get
done much faster that way. A stock/custom unification could be a
Yep the old compromise.
To view or change your list settings, click here:
More information about the developers