New custom fields proposal

[Gervase Markham]

Sean McAfee wrote:
> Enclosed is my proposal for new custom field functionality to be added to
> Bugzilla.  

Sorry it's taken me so long to read this.

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

As I think someone else has commented, I strongly suggest that they be 
per-product. That's the scope we tend to use for this sort of thing; the 
idea is that you should be able to move bugs between components without 
any values of any other fields (or their very existence) becoming invalid.

> Custom fields will be available in five major varieties: integer,
> float, string, date, and selection.  The first four of these types are
> collectively referred to as "scalar" types.  All scalar fields can be
> set to a special "undefined" value in additional to the valid values
> described below.

Do we need float? We don't have any float fields right now. I guess if 
it doesn't complicate things then it doesn't matter too much whether we 
have it or not.

> [Open question: Should integer fields be available in signed and
> unsigned varieties?]

No. They should be signed only.

> [Open question: Should Bugzilla transparently offer large-integer
> semantics?]

No. This is an unnecessary complication.

> Bugzilla may emit client-side scripting code onto any pages that
> request custom-field input that will abort form submission if an
> integer field's submitted value is out of range.

Hmm. Maybe. But we should never depend on its existence.

>    +  an optional exponent, expressed as an 'E' or 'e' character,
>          followed by an optional plus sign ('+') or minus sign ('-'),
>          followed by a sequence of digits

Do we really need to go this far? If the parsing library gives us this 
for free, then OK, but who would really store massive floats in a 
Bugzilla field?

> [Open question: Should Bugzilla reject attempts to store arbitrary
> binary data in a string field?]

No. String data should be 8-bit safe, for l10n reasons if no others.

> Each string field is flagged as belonging to one of two varieties:
> short and long.  A short string field can hold a maximum of 255
> characters, and may contain no vertical whitespace characters
> (carriage return, newline, or vertical tab).  It is represented on
> Bugzilla's Web interface using a single-line text form element.  A
> long string field can hold large amounts of text, possibly consisting
> of several lines.  It is represented on Bugzilla's Web interface as a
> multiline textarea form element.

Is there a max size for the long field? I think 32K should be OK.

> Date
> ----
> [Open question:  Is the "time of day" subtype really necessary?]

No, IMO, unless you can think of a very good use for it.

> [Open question: Is this too busy?  Should a simple text-entry widget
> suffice for all date types?]

I'd say it's too busy. A text widget which takes only 2003-03-03 format 
dates would be fine. That's much quicker and easier to use, once 
learned, than multiple widgets.

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

Why would one need a 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.  

This is all very snazzy, but does anyone have a use for it? :-)

> [Open question:  Should the field subtypes described above really be
> their own top-level types?]

Makes sense to me. Multi-select and single-select.

> Presentation
> ============
> 
> Custom fields are to be presented on each Bugzilla page that presents
> the standard Bugzilla fields.  These pages include at least the
> following:
> 
> On "show_bug.cgi" and "post_bug.cgi", the custom fields should be
> shown just prior to the list of attachments.
> 
> On "enter_bug.cgi" and "long_list.cgi", the custom fields should be
> shown just after the "Description" text box.

I don't think the custom fields design has to specify how the fields are 
represented on the page. But, if you want to discuss it, I think it 
depends what sort of field it is. For example, on the show_bug page, 
String fields would be below the other four/five String fields (QA, URL 
etc.)

Moving to a CSS-based layout should make it much easier to add and 
remove fields.

Also, while the default templates should contain generic code for 
displaying any custom fields, it should also be possible for admins to 
hard-code the position of the field themselves, and flag in the template 
that they've done so so that the template doesn't print it again.

> The query.cgi page requires more extensive modifications.

Not necessarily; you could just add them to Boolean charts, and say that 
admins have to edit the template to get better support. That would be a 
valid position.

> Here is an alternate approach.  A button is to be added to the query
> page, to the right of the "Product", "Component", and "Version"
> listboxes, labelled "Show custom fields for these components".  If the
> user clicks it, the query form is redisplayed, augmented with all
> custom fields in all of the selected components.  If no components
> were selected, or if no selected component has any custom fields, the
> page is simply redisplayed as it was before.

Hmm.

If a custom field is global, it would always be shown, of course. If 
there are no non-global custom fields, the button would not appear.

Or, you could just display UI for all custom fields, and return zarro 
boogs if they queried on a custom field value in a Product for which it 
was not available. It depends how many custom fields people might want; 
if it's loads, this approach might not scale.

Anyway, I think this UI needs a lot more thought.

Now, I'm going to go and read what everyone else said :-)

Gerv