Partial custom fields design document

[Jon Wilmoth]

Sean's original proposal called for custom fields to be both global
and/or product specific.  For whatever it's worth, this is the
functionality I would like to see implemented.  An example of how we
would use both:

Global custom field:
Starbucks Systems Methodology phase

Per product:
For logistics related products, an "affected" distribution center would
be a welcome classification.  However, HR or financial related product
users would not want to see/be confused by the decision to pick an
"affected DC".

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org] On Behalf Of Joel Peshkin
Sent: Saturday, March 27, 2004 5:49 AM
To: developers at bugzilla.org
Subject: Re: Partial custom fields design document

Gervase Markham wrote:

>
> If we are making custom fields product-specific instead of global 
> (which I believe is the plan), then we shouldn't add them to the bugs 
> table.
>
The problem with that particular item is that it is a terrible plan.  
Having custom fields come and go from the UI on a per-product basis is 
great.  Having them come and go from the DB on a per-product basis is a 
recipe for dataloss.  Once a bug has a custom field, it should be stuck 
with that field forever, even if it is moved to a product where that 
field is not supported and then back again.



-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth@starbucks.com>