Partial custom fields design document
Steven Suson
suson at TuckerEnergy.com
Tue Mar 30 00:29:47 UTC 2004
I very much agree. Need both global and product specific.
Steven Suson
Jon Wilmoth wrote:
>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>
>
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=suson@tuckerenergy.com>
>
>
More information about the developers
mailing list