Custom Fields again

[Gervase Markham]

Over in
http://bugzilla.mozilla.org/show_bug.cgi?id=91037
Dave said:

"The current thinking is that we decide what the core types of these 
fields are that we need to have available, and provide 3 or 4 of each 
hardwired in the bugs table with a UI in the admin interface for 
customizing the labels shown to the users or hiding/showing those 
fields.  This gives you a limited ability for adding custom fields, 
while not creating headaches and performance issues with multiple joins 
during queries."

This solution seems to me to get the worst features of custom fields 
without getting any of the good ones. We all know that
http://www.joelonsoftware.com/news/20020912.html
is why we are considering not having them. Joel argues that having 
custom fields leads to people defining fields they don't really need, 
field proliferation, and a a general muddle. The above plan doesn't 
avoid that - it merely limits admins to 3 confusing email fields, 3 
confusing multi-selects and 3 confusing text fields.

In addition, this not-quite-generalisation means our code will be 
scattered with references to generic_text_field1, generic_multiselect2 
or whatever we decide to call these generic fields when we add them to 
the bugs table. These will be carried around whether the user is using 
them or not.

An advantage given above is that general custom fields mean performance 
issues with multiple joins during queries, and this method avoids that. 
But this is thinking from an engineering point of view, not a usability 
one. If this is a problem, then big installations can content themselves 
with the default fields and do no joins. Or they can use mod_perl to 
improve performance in other ways. Or get a better database, that does 
lots of joins quicker. Or we could optimise our queries in a smarter way.

Enough of this halfway house! :-) Let's have full custom fields, 
implemented in a clean, generic and sensible way, or not at all. :-)

Gerv