New custom fields proposal
etzwane at schwag.org
Thu Apr 10 01:13:05 UTC 2003
"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" sense.
>Date fields are represented on Bugzilla's web interface using a pair
>of drop-down listbox form elements (for the month and day) and a
>single-line text-entry element (for the year) for the date portion of
>the field's value (if appropriate), and a single-line text entry
>widget for the time portion (if appropriate). Bugzilla should signal
>an error if an invalid date or time is submitted.
>[Open question: Is this too busy? Should a simple text-entry widget
>suffice for all date types?]
>IMHO, yes...it's too busy. If it's a date field it would be more useful
>to have a popup calendar (bottom of which could also include time
>elements). I would think a date field should have a input pattern that
>could vary on a field by field basis. This can be compared to java's
>simple date format
>) class or oracle's to_date fuction that allow for a pattern (i.e.
>MM/dd/yyyy HH:mm:ss aa zz to define a date input valid for 04/08/2003
>16:25:30 pm PDT)
Sounds reasonable to me. I've never incorporated one of those calendar
popups into any of the pages I've created, but I imagine it can't be too
>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 displayed
length of a single selection field. I wouldn't mind chopping displayed
selection values at some reasonable length limit, but in that case the admin
interface should probably display a warning if an attempt is made to create
selection values which exceed this limit.
>Each selection field's set of allowed values may be specified in one
>of two ways. A "local" selection field's values are defined by the
>Bugzilla administrator, and are managed by Bugzilla itself. A
>"remote" selection field's values are taken from a table in a database
>which need not be the same database used by Bugzilla. The
>administrator defines the remote database in the form of a DBI connect
>string, a username and password with which to log in to the other
>database, a table name, and a column name. Bugzilla generates the set
>of allowed values by logging in to the remote database using the
>supplied username and password, and issuing the following query:
>While the "remote" concept is cool, I think it should receive a lower
>priority and perhaps even be treated as a separate release of "custom
>fields". There's a lot of work to do as is to manage "local" custom
That's fine with me. I was perhaps copying features too liberally from our
existing system (TeamTrack), which offers a feature like this (although only
for tables in TeamTrack's local database).
>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 common
information that applies to *every* product?
>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 view
(as far as I know). Do you mean that a "required" field would be required
only when a bug is first created?
>Presentation - Error messages, Labels and references to the custom field
>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?
>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 separate
More information about the developers