Custom fields schema

[Sean McAfee]

"Kevin Benton" <kevin.benton at amd.com> wrote:
>It seems to me that any discussion of custom fields ought to include
>existing fields and handle them all in a unified approach.  In my view, the
>best way to do this would be to define every field in a fields table, and
>specify formatting / location, etc. in the table.

I'd like to get there eventually, but for an initial custom fields release,
I'd prefer to think a little smaller.  After all, converting built-in fields
to custom fields later should be a snap:

INSERT INTO custom_fields VALUES (
    NULL, 'creation_ts', 'Creation Time', 't', NULL
);

SELECT LAST_INSERT_ID();  -- say it's "42"

INSERT INTO CF_DATE
SELECT bug_id, 42, creation_ts
FROM bugs;

ALTER TABLE bugs DROP COLUMN creation_ts;

The data conversion would be a snap, I mean; lots of code would obviously
have to be rewritten.

>I would hope that there
>would even be a place where that table would have a definition for certain
>types of handlers (subs) associated with each field.  Maybe this is an
>overly complex a view, but I think that this might offer us more flexibility
>than we have with TT and yet, give us the ability to handle fields we
>haven't dreamed of through plugins.

I've also implemented something like this.  I have a module Bugzilla::Local,
where site-specific behavior can be defined.  For example, there's an
exported subroutine in there called "auto_fields", which describes how to
automatically fill in certain fields when a bug is created.  We wanted to
maintain some continuity in the bug-numbering scheme of our old tracking
system, so I created a custom field to hold this number, and when a bug is
created in the relevant product, auto_fields() sets that field's value in
the new bug to one higher than the current highest value.


--Sean