An alternate approach to custom fields

[Sean McAfee]

My company is looking to replace its current incident-tracking system
(TeamTrack).  We want to keep as many of its good features as possible while
doing away with the flaws that are a continual source of headaches--the
horrible performance, mostly, although its proprietary, black-box nature is
also annoying.

I've examined a good number of free systems, and Bugzilla appears to offer
most of the features that we'd like.  One feature is lacking, however, that
we'd really hate to do without: custom fields.

I've read the "Living Without Custom Fields" essay at
<http://www.gerv.net/hacking/custom-fields.html>.  I had little success
trying to apply the existing custom-fields patch.  None of the other
suggestions really address all of the situations that might arise here.
For example, one of our workflows describes the testing path of individual
returned parts.  Each part is run through a dozen or more tests.  The result
of each test is recorded via a drop-down list on our current system's web
interface.  Different tests are performed at different times.  Trying to
squeeze all of this information into a single free-form text field and
depending on users to keep the field formatted in a way that's suitable
for querying seems like a recipe for disaster.

I've thought up a possible way of implementing custom fields by combining
options 2, 4, and 6 from the "Living Without" page ("Bug entry templates",
"Co-opt an existing field", and "Hacking" respectively).  It seems feasible
to me, but I'm not sufficiently familiar with the Bugzilla internals to
feel really confident about my assessment.  So I thought I'd toss my plan
out on the developers' list and see what y'all thought.

In a nutshell, the plan is this:

1.  Co-opt an unused text field and use it to store a serialized
    representation of my desired custom fields--using XML, say.  

2.  Add a call to the bug entry and bug editing templates that expands the
    serialized custom fields into additional HTML form elements.

3.  Modify the targets of the previous two pages such that they collapse the
    extra form elements back into serialized form.

Even a basic approach like this would supply much of the functionality we'd
hate to have to do without, but I can easily see building more sophisticated
layers on top of it: state-dependent views, per-project fields, etc.

As far as I can tell, the extra features I'm proposing would be largely
orthogonal to the existing Bugzilla codebase, and thus easy to maintain as
new versions of Bugzilla are released.  The only exception is querying; I
wouldn't want to have to figure out how to incorporate searching on custom
fields into the existing framework.  I'm willing to live without this
feature, however, at least via the web browser.  I can envision a new Perl
query library that transparently presents the custom fields alongside the
standard ones.

So, how does all of this sound?  Has it been tried before, with disastrous
results?  Any obvious gotchas that I'm missing?

Thanks in advance for any advice.

-- 
Sean McAfee
etzwane at schwag.org