An alternate approach to custom fields
JWilmoth at starbucks.com
Sat Mar 22 00:59:05 UTC 2003
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.
I'd also like to see a merger of the 'customfields' (from patch) and the
'fielddefs' tables. I think it would be valuable for an admin
perspective to make fields required/validated and change the
label/description on a per install basis. This would also allow single
"field" definition/maintenance paradigm. Furthermore, it will allow for
quick resolution of a number of bugs that are waiting for this (i.e.
"must have by" field, etc.)
Thus something like (fielddefs):
Name - human-readable unique identifier (pk). An numeric ID column
wouldn't be necessary?
Label - The human readable text presented to the user (Template would
need to be refactored to apply this to existing fields).
Type - ? is this necessary? What value does this provide if validation
regexps are enforced against the content? constraint restricted to valid
Multi - flag indicating user may select multiple values
SortKey - Display order
Required - flag indicating a value must be submitted. Should be able to
be overridden at lower (i.e. product specific levels).
Valexp - regular expression describing the valid pattern of input. If
null, no validation is performed. (also overrideable at lower level).
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
From: Bradley Baetz [mailto:bbaetz at acm.org]
Sent: Friday, March 21, 2003 2:18 PM
To: developers at bugzilla.org
Subject: Re: An alternate approach to custom fields
On Fri, Mar 21, 2003 at 12:15:32PM -0500, Christopher Hicks wrote:
> On Fri, 21 Mar 2003, Gervase Markham wrote:
> > bbaetz outlined how we would like this to work in a message on the
> > of this month:
> bbaetz' answer sounds good as far as storing the data, but he left out
> table for storing this mapping information.
We already have a fielddefs table - we'd just have to extend it a bit
> Having the mapping
> information in the database has always been essential in my
> If this information doesn't ride along with the data you have to
> it as part of the code which would undermine the value of making the
> custom fields generalizations in the first place
> For instance:
> "FKID" would identify the foreign key. Above I've used an integer to
> indicate this which would point to a portion of a codes table. bbaetz
> answer implied he'd prefer to have a seperate table for each foreign
> so having a table name here might be necessary for his approval. I'd
> encourage having a single table for such simple code lookups however.
> you're not using relational integrity and you're not stuck in the
> Relational perspective, it tends to lead to a lot less clutter and it
> makes creating an interface to let people maintain codes easier.
We will be using referential integrity. That said, we could probably
enforce it via a trigger, except for mysql.
> "Multi" would indicate whether multiple instances of that field are
That precludes a unique constraint when its not.
Now, this would all be simpler if we coudl store it in multiple tables,
and then have a VIEW with a UNION ALL query to bring them all together.
To view or change your list settings, click here:
More information about the developers