Custom Fields again

[Gervase Markham]

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?

Gerv