Custom fields schema

[Joel Peshkin]

Sean McAfee wrote:

>CREATE TABLE custom_fields (
>    field_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
>    field_name VARCHAR(100) NOT NULL,
>    display_name TINYTEXT NOT NULL,
>    field_type CHAR BINARY NOT NULL,
>    selection_id INTEGER,
>    UNIQUE INDEX (field_name)
>);
>
>This is obviously the table which enumerates all custom fields defined at a
>particular Bugzilla installation.
>
>  
>
Let's merge this with fielddefs.  It would be a shame to make every bit 
of code have to query both fielddefs and custom_fields.  At first glance 
that may seem like more work, but it will not be by the time we are done 
with buglist.cgi, Search.pm, and BugMail.pm.

Also, do we need accesskeys for customfields? 

>print "field value is ", $bug->{my_custom_field}, "\n";
>
>On ongoing but minor concern of mine has been how to guarantee that a custom
>field's name does not conflict with any CGI parameter, now or in the future.
>Adopting a naming convention, such as a short prefix followed by "_", has
>seemed to suffice.
>  
>
Sounds good.

>There has been disagreement on this mailing list in the past, since this
>approach is not internationalization-friendly.  Recently it occurred to me
>that a compromise might be to use templates to look up field display names,
>as others have proposed (or insisted upon), but to fall back on the contents
>of this column if no template-based name is found.
>
>  
>
Sounds good.

>field_type obviously describes the type of the field.  Valid values are:
>
>'i' - An integer.
>
>'d' - A date with no associated time.
>
>'t' - A date/time.
>
>'s' - A short string, 255 or fewer characters in length.  No vertical
>      whitespace allowed.  Represented on CGI forms by a single-line text
>      element.
>
>'l' - A long string, 65535 or fewer characters in length.  No restriction on
>      contents.  Represented on CGI forms by a textarea element.
>
>'e' - A "selection" field, which takes its values from a set of valid
>      strings, its "domain".  Such a field's value may be either exactly one
>      or zero of the elements of its domain.
>
>'m' - A "multiselection" field.  Like a selection field, but its value may
>      consist of any number of elements of its domain.
>  
>
I think a single character may not be sufficient in the long run.  This 
looks like a reasonable initial set, but I can see subsequent patches 
adding 'u' for a userid.  Ideally, it would be nice to be able to 
specify i(userid) or some more inspired syntax to indicate that the 
field is an integer holding a userid, etc...

>More recently, I've had a need to address custom fields and built-in
>Bugzilla fields using the same range of integers, so I added an eighth field
>type: 'b', for Bugzilla.
>  
>
Please explain

I think that we need to determine what should happen with bugmail and 
customfields.  My suggestion is that, as we merge fielddefs and 
custom_fields, we replace mailhead with something slightly more useful.

We should also determine what expectations we have from the UI.  I still 
believe that the right thing to do is to make things work if the 
templates know nothing about the new fields, but give template authors 
the ability to "take over" some fields while leaving others to the 
default processing.