New custom fields proposal

[Sean McAfee]

"Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
>Thoughts/question inline...

>Definition
>==========
>
>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".

><feedback>
>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.
></feedback>

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?]

><feedback>
>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
>(http://java.sun.com/j2se/1.4.1/docs/api/java/text/SimpleDateFormat.html
>) 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)
></feedback>

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
difficult.

>Selection
>---------
>
>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?]

><feedback>
>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.
></feedback>

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:

><feedback>
>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
>fields.
></feedback>

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.

><feedback>
>I'd like to see two levels of scoping global and by product for custom
>fields.  Anything else is gravy.
></feedback>

Is it normal that a Bugzilla installation will want to define some common
information that applies to *every* product?

><feedback>
>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.
></feedback>

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
phase.


--Sean