New custom fields proposal

[Sean McAfee]

Bradley Baetz <bbaetz at acm.org> wrote:
>On Wed, Apr 09, 2003 at 09:55:36PM -0400, Sean McAfee wrote:
>> I'm not so familiar with real-world use of Bugzilla yet.  It was my
>> perception that "Product" and "Component" formed a two-level hierarchy
>> within which bug categories could be arbitrarily placed.  You seem to be
>> saying that Components within a Product are necessarily related in some way.
>> Correct?

>Well, its a hierarchy. So the stuff lower down is related to the stuff
>higher up, sort of by definition.

I'd been thinking about the product/component relationship more like a
filesystem, which is also a hierarchy, but with no particular relationship
between levels.

>IT may be useful to do this on a per
>component basis, but lets start with per product.

OK, I don't mind starting with per-product.  (And global, which some folks
seem to like.)

>> >No, an entry should always have to be selected. If people want a none
>> >option, then they can add it to teh select list. It makes the code a
>> >lost timpler, not to mention the ui.

>> As long as a "None" option is provided by default when a custom selection
>> field is created, I suppose I have no objection.

>We'll probbaly insert something just to make things easier, and refuse
>to allow the last element to be removed - it makes stuff easier.

Can "None" (or a similar word) be a special, reserved selection value?  I'm
thinking ahead to when I might want to programmatically determine whether a
particular field has been set by a user yet.  This won't be easy if each
selection field gets its own notion of what being "unset" is called.

>> >Show them all, or at least those which are avliable on products the user
>> >has privs to see.

>> Well, first of all, some of the projects I have here which I plan to
>> convert from TeamTrack to Bugzilla contain dozens of custom fields.  The
>> query page would quickly become very long if they were all always shown.
>> 
>> Secondly, it's misleading to present query elements which may have no
>> bearing on the final query.  What should Bugzilla do if the user enters a
>> query term for project Foo, but then searches project Bar?  Raise an error?
>> Silently ignore?

>Well, this doesn't solve that problem - what if you search on (product
>is a or product is b) and (custfield-a is ? or custfield-b is ?)? You
>still need an answer for that...

According to my proposal, the user would select projects "a" and "b" at the
top of the page, press the "Show custom fields" button, and be presented
with all of the custom fields for projects "a" and "b".  At this point the
situation is the same as your "always show all custom fields in all projects"
approach, since fields in projects other than "a" and "b" are irrelevant.

Another option which since occurred to me is to use Javascript.  Include all
custom fields, but group them in per-project <DIV> elements which initially
have the style "display: none".  An event handler attached to the "Project"
selection element would dynamically toggle the display styles between
"inline" and "none".  Is this reasonable?  Is there some minimum level of
scriptability we should expect from Bugzilla web clients?


--Sean