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