An alternate approach to custom fields

[Bradley Baetz]

On Fri, Mar 14, 2003 at 07:10:42PM -0500, Sean McAfee wrote:
> 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.

If the tests are just a pass/fail basis, then you could use keywords or
(in 2.17) bug flags to represent the various tests. If you sometimes run
tests more than once, then you'll have to use bug flags.

If they're not just pass/fail, you could probably hack the +/-/? bits to
have more options. If they're freeform comments, then it could be more
complicated, if you don't want to just have them in there as normal
comments

> In a nutshell, the plan is this:
> 

<snip>

I suspect that the effort involved in doing that (especially if you want
to search) is probably more than the effort required to get custom
fields done properly.

There are bugs with searches on some of the flag fields, but they're
still easier to fix than having the search routines somehow grovel
through xml (or any other format)

> 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.
> 

Thats the plan (using Bugzilla::Search, basically)

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

I'm not aware of anyone having tried to handle custom fields via xml
serialisation.

The issue with custom fields is not that we don't know how to do it, but
that none of the developers have time to do it.

Bradley