Custom Fields again
gerv at mozilla.org
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