Custom fields design doc

[Gervase Markham]

Sean McAfee wrote:

> field_id integer auto_increment primary key,
> field_name tinytext not null,
> display_name tinytext not null,

If this isn't in templates, it can't be localised - i.e. you can only 
have a single value, no matter how many nationalities of people use your 
Bugzilla. I still think we should have a mechanism where it uses 
field_name to begin with, and you then define display names in templates 
on a per-language basis...

> field_type char binary not null,
> required bool not null,
> selection_id integer references cf_selections(selection_id)
> 
> The field_type column is 'i' for integer fields, 'c' for short string
> fields, 'C' for long string fields, 'd' for date-only fields, 'D' for
> date-time fields, 's' for single-selection fields, and 'S' for
> multiselection fields.

The following make more sense to me:
i: integer
s: string
l: long string
d: date
t: date-time
e: single-select (e for enum; OK, this one's a bit iffy)
m: multi-select

The upper/lower case distinction doesn't always mean the same thing, so 
is a bit confusing IMO.

> The selection_id column is an index to the cf_selections and
> cf_selection_labels tables for fields of type Selection, and is NULL
> for other types.
> 
> cf_groups
> ---------
> group_id integer auto_increment primary key,
> group_name tinytext
> 
> This table contains one row for every custom field group.  The name
> may be NULL for reasons described below.

I'm having trouble understanding this proposal, because of one big 
question: what's a custom field group?

> cf_product_members
> ------------------
> product smallint references products(id),
> group_id integer not null references cf_groups(group_id),
> display_index integer not null,
> index (product)
> 
> This table describes which groups belong to which products, and the
> order in which the groups should be displayed to users.  The global
> scope is described by rows with product = NULL.

"display_index" should have the same name as the fields which do the 
same thing in other tables (can't remember what it is offhand.)

> cf_selections
> -------------
> selection_id integer auto_increment primary key,
> unset_label tinytext not null
> 
> The unset_label column is the text which represents the "empty set"
> value of single-selection fields.
> 
> cf_selection_labels
> -------------------
> label_id integer auto_increment primary key,
> selection_id integer not null references cf_selections(selection_id),
> label_index integer not null,
> label tinytext not null,
> index (selection_id)

Why can these two tables not be combined?

> For each single-selection field, there is one row in the table.  The
> selection_id is NULL if the field is unset; otherwise it references a
> row in the cf_selection_labels table.

Surely "there's no row present if the field is unset"? This matches the 
behaviour for multi-selects.

> For each multiselection field, there are as many rows in the table as
> there are selected strings in the field's value.  Each selection_id
> references a row in the cf_selection_labels table.
> 
> *****
> 
> The following six tables hold bug activity data.

Dude, scrap this! Use our current tables for bug activity data. Please! 
:-) Store the name of the field, what it changed from, and what it 
changed to, just like now. That's fine. Really.

> FILE SYSTEM
> ===========
> 
> All custom-field-related templates go in the directory
> $BUGZILLA_ROOT/template/en/default/custom.

That's rather confusing, because we have a template/en/custom for custom 
templates. You could have "custom-fields", which would be better, but 
otherwise they'd just live in whichever part of the template tree they 
were relevant to.

> ADMINISTRATION
> ==============
> 
> Each page contains a single form, which always contains a hidden field
> called "context".

We call this "action" everywhere else.

> Initial page
> ------------
> Context:  choose-scope
> Template: template/en/default/custom/choose-scope.html.tmpl
> 
> The user may select a scope via either of the following three elements:

What is a scope?

Regarding the rest of the proposal: I may well have comments, but I 
can't make them until some of the big questions (like: what is all this 
groups stuff?) are answered.

And, importantly, if this is a design document, there is no place in it 
for code. It's just obfuscating, and premature detail.

If you are in fact in the middle of implementing this exactly as you've 
designed it above, you might as well say so and be done with it :-)

Gerv