The Road to 2.18 - Customfields

[Joel Peshkin]

Steven Suson wrote:

> I too perhaps should've posted my two cents worth earlier. There are 
> just two things that I wanted to say. One, that when discussing the 
> design issues, waiting, etc., that "best is the enemy of good enough." 
> And the other, that my company has been waiting approximately a year 
> for an extension of functionality to bugzilla, which is FULLY provided 
> by custom fields. I pity our poor secretary who is forced to 
> supplement our use of bugzilla, using paper and PDF forms. Therefore, 
> I heartily support Sean in his efforts.
>
> Steven Suson


Unfortunately, none of the patches seen to date is "good enough" at 
all.  The team cannot just merge in a patch that is not written in a 
manner that will permit smooth upgrades from version to version, etc..

I agree that we should not require the first customfields patch to do 
everything imaginable.  There are a base set of design decisions that 
need to be agreed to and then a patch, consistent with the standards of 
the overall project, can be written an landed.  The problem is that 
nobody has done that.

I suggest that the following requirements be accepted.....

1) Schema changes must be made by checksetup in the standard way
2) Creation of new fields can be done either using the web (preferred) 
or localconfig/checksetup
3) All activity log functions must still work with customfields.  If 
this means that the activity log mechansim needs to be replaced, the old 
log information must be ported by the upgrade.
4) GUI forms must include custom fields and work, but need not be pretty
5) Possibly in a subsequent release, custom templates should be able to 
"hook" custom fields and handle them, overriding the builtin GUI 
generation that may be ugly or insufficiently localized.
6) Customfields that are missing from a bug form should never cause an 
error or deletion of a customfield when a bug edit is processed.
7) Email notification of customfield changes should work and be selectable.
8) If customfields are product-specific, no information should be lost 
on product change, even if the bug is changed to a product that does not 
use that field and back again.
9) No really bad SQL should be used.  Multiple choices must be handled 
by one-to-many relations in the database, not by concatenating multiple 
items in strings.

Notice that I didn't even say if I care if the patch supports multiple 
datatypes, etc... so long as the schema doesn't preclude adding 
additional types later.

Now, if someone writes a real proposal, we can get consensus on it and 
go forward.  Someone could also skip that step, spend months writing 
code, and then get frustrated when the code cannot land.

-Joel [not on anything, especially software]