Custom fields schema
etzwane at schwag.org
Wed Dec 15 23:11:25 UTC 2004
"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
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.
More information about the developers