Custom Fields again

Gervase Markham gerv at
Tue Dec 10 23:28:32 UTC 2002

David Miller wrote:
> We already use LearnAboutColumns() to find out what the names of the
> columns are in the bugs table and just look for any field in the bug form
> with the same name to insert into a bug when creating it.  A custom field
> (at least for creating the bug - querying is a separate issue) would simply
> be a matter of editing the enter_bug template to display it, and adding the
> column to the database.  No code changes would even be required.

Indeed. I assumed that adding extra columns to the bugs table was the 
way we were going to implement it; I didn't even consider that there 
might be another option.

As I see it, it would work as follows:
- When you define a new field, you define an alphanumeric name/tag (e.g. 
"buildid"), a description ("Build ID") and a type ("text").
- For single-select or text fields, we would then add an extra column to 
the bugs table of that type with that name.
- For multi-select fields would instead have an extra table of that 
name, which mapped bug IDs to values.
- show_bug would display all fields it could find in a sane way; for 
example, there'd be a vertical column of text fields, much like now, and 
multi-selects would be three across the page.
- query.cgi would provide suitable query UI depending on field type.
- Of course, the layout of both the above would be customisable; you 
would hard-code using a form name of the tag defined above, which fits 
with current practice of using DB column names for form names.

Anyone else thinking along these lines?


More information about the developers mailing list