The Road to 2.18 - Customfields

[Stuart Donaldson]

This is a great start at getting a set of requirements identified.

I think we should prioritize the requirements.  What is mandatory, and 
what would be nice to have. Mandatory means that a solution MUST meat 
that requirement.  The nice to haves, are things that could be done by a 
solution, but are not required right now.  These might also be debatable 
as to their need, or how to do it.

Some of the things Joel mentions I think fit the later category...

Joel Peshkin wrote:

> 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

Someone recently posted a concern about using a web interface to create 
custom fields.  I share the concern that a web interface makes it too 
easy to add custom fields, and may encourage bad use of bugzilla.  I 
think it would make much more sense to be implemented via 
localconfig/checksetup such that it forces a little more forethought 
into the process.  Furthermore, I suspect a localconfig/checksetup 
solution would reduce the complexity of the implementation.

A requirement for a web interface for the setup should be postponed.  
Although if we want the option of a web interface, then we should state 
that the entire custom fields definition must be represented in the 
database, rather than in code loaded in localconfig.

> 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]
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=stu@asyn.com>
>
>