An alternate approach to custom fields

[Gervase Markham]

Jon Wilmoth wrote:
> Can some one who has a solid understanding of the bugzilla inners
> workings  describe the relationship between the fielddefs table,
> field-descs.html.tmpl and their effect on the ui?  I've changed
> description values in the table and the field-descs with no affect on
> the bug entry, query, or query results page.

The description field is deprecated; it can't live in there for 
localisation reasons.

Fields should be uniquely identified by a short string consisting of 
letters and underscores only, which can be used as a form field name, 
database column name etc.

> I'd also like to see a merger of the 'customfields' (from patch) and the
> 'fielddefs' tables.

Please don't think you need to base your work on the existing patch, or 
necessarily use any of the ideas or schemas contained therein.

> Thus something like (fielddefs):
> Name - human-readable unique identifier (pk).  An numeric ID column
> wouldn't be necessary?

Always have a numerical ID. :-)

> Label - The human readable text presented to the user (Template would
> need to be refactored to apply this to existing fields).

This should not be in the table - see above, and the 
field-descs.html.tmpl template in Bugzilla.

> Type - ? is this necessary?  What value does this provide if validation
> regexps are enforced against the content? constraint restricted to valid
> data types.

We need a type, because we want to store strings as strings and integers 
as integers, for speed reasons.

> Multi - flag indicating user may select multiple values
> 
> SortKey - Display order

Where these have appeared elsewhere in Bugzilla, they have been a pain. 
Why is it needed?

> Required - flag indicating a value must be submitted.  Should be able to
> be overridden at lower (i.e. product specific levels).

You mean on bug entry? We don't need this in the table - policy such as 
this is enforced at a much higher level.

> Valexp - regular expression describing the valid pattern of input.  If
> null, no validation is performed.  (also overrideable at lower level).

Again, I'm not convinced we need this (other than the definition of enum 
types.)

> System - flag indicating this field is part of the base distribution and
> must be present for the correct functioning of Bugzilla (i.e. a not
> deletable flag).

Surely the point of custom fields is that they are custom? Or is this a 
way to distinguish those fields currently in the fielddefs table from 
the new ones?

Gerv