New custom fields proposal

[Jon Wilmoth]

-----Original Message-----
From: Sean McAfee [mailto:etzwane at schwag.org] 
Sent: Wednesday, April 09, 2003 6:13 PM
To: developers at bugzilla.org
Subject: Re: New custom fields proposal

"Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
>Thoughts/question inline...

>Definition
>==========
>
>Currently, Bugzilla offers a fixed number of named fields to describe
>bugs.  These fields are shared across every component in the system.
>The proposed additional functionalty is the ability to define
>additional fields on a per-component basis.  These additional fields
>are called "custom fields".

><feedback>
>I assume your talking about "component" being a broad system module
>(i.e. search, creation, reporting, etc.).  I'd suggest you use a
>different term so as not to be confused with a Product component.
></feedback>

Er, no, actually.  I did mean "component" in the "Product component"
sense.


I think component specific custom fields might be valuable in the future
however I agree with the statement there are serious cons with that
approach.  I'd stick with per product and global.


>Selection
>---------
>
>A selection field takes its value from a set of distinct string
>values.  No string value in any selection field's set of valid values
>may contain vertical whitespace, contain leading or trailing
>whitespace, or exceed 255 characters in length.
>
>[Open question: Should there be a limit on the size of the set of
>valid strings?  If so, should this limit be global or per-component?]

><feedback>
>The main issue here is screen real-estate which is a global issue.
>Having unlimited select lists can throw the html tables out of wack.
>I'd suggest a global limit set to the largest possible value for the UI
>where custom fields will be added.
></feedback>

I was talking about the total number of selections allowed in a single
selection field, whereas you seem to be referring to the maximum
displayed
length of a single selection field.  I wouldn't mind chopping displayed
selection values at some reasonable length limit, but in that case the
admin
interface should probably display a warning if an attempt is made to
create
selection values which exceed this limit.

Agreed, admins will need to know a max length.  I would suggest
restricting admins from violating the max length rather than warning and
truncating.  Also I don't think the system should impose a constraint on
the number of values available.  Certainly there are usability issues
when a list gets too long, but let's make the Bugzilla administrators
accountable for some common sense things.

>Different components may define different custom fields with the same
>name.  Therefore, custom field form elements for custom fields
>belonging to the same component will need to be grouped together,
>clearly labelled as belonging to that component.

><feedback>
>I'd like to see two levels of scoping global and by product for custom
>fields.  Anything else is gravy.
></feedback>

Is it normal that a Bugzilla installation will want to define some
common
information that applies to *every* product?

In my experience yes.  We may have a "need by date" that all dev teams
use, but certain products may have special "value add" fields like test
lab location or bandwidth elements that don't apply to other products.

><feedback>
>Security - Assign access to custom fields to groups.  Assignment would
>hide fields from being displayed.
>
>Validation - Required vs. not required.  In addition to the type
>checking described above, a required flag should be included in the
>definition of the field.

I thought of including this, as TeamTrack offers it, but there a field's
"required" status is based on an incident's state within its enclosing
project's workflow.  Bugzilla doesn't offer a similar state-dependent
view
(as far as I know).  Do you mean that a "required" field would be
required
only when a bug is first created?

I agree that often there is more value in state-aware constraints than
not.  For simplicity sake, my suggestion would be to do a first cut of
either required or not...no state considerations.  If this is
toggleable, admins can select values appropriate to their "typical
state".

>Presentation - Error messages, Labels and references to the custom
field
>names (i.e. contextual help pages) should allow for the displaying of a
>system admin controlled term.

I'm not sure I understand.  Can you provide some examples?

Let's say I add a "NeedBy" field, the field may have a systematic name
or identifier and it will should have a user-friendly name "i.e. "Need
By Date".  The label next to the field, any popup error msgs etc. should
use the text "Need By Date" rather than "NeedBy" or "customField4".

>Consistency - It would be nice to have a uniform approach to field
>definitions (security, validation, and presentation) for both stock and
>custom fields alike.
></feedback>

I agree that it would be nice--very nice, even--but I'd prefer to keep
custom fields orthogonal and avoid modifying Bugzilla's core.  We'll get
done much faster that way.  A stock/custom unification could be a
separate
phase.

Yep the old compromise.

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