An alternate approach to custom fields

[Jon Wilmoth]

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
data types.

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
deletable flag).


-----Original Message-----
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
1st 
> > of this month:
> 
> bbaetz' answer sounds good as far as storing the data, but he left out
a 
> 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
experience.
> If this information doesn't ride along with the data you have to
maintain 
> 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
key,
> 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.
If
> you're not using relational integrity and you're not stuck in the
Orthodox
> 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 
> allowed.
> 

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.

But....

Bradley
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth@starbucks.com>