An alternate approach to custom fields
gerv at mozilla.org
Sat Mar 22 10:03:04 UTC 2003
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
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
> 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?
More information about the developers