New custom fields proposal

[Bradley Baetz]

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. IT may be useful to do this on a per
component basis, but lets start with per product. Flags are per
component, but the moving cases are broken with that.

> Time-of-day was another (probably unnecessary) carryover from TeamTrack.  I
> don't mind getting rid of it.  But I think a distinction between date-only
> and date-plus-time-of-day could still be useful.  The former might describe
> when a shipment of parts arrived, and the latter might describe when during
> a particular day that a test was performed on one of those parts.

Well, bugzilla is a bug tracking tool, remember...

> >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.

> >No. Enforcement _must_ be done on the server, or rather it must be able
> >to be done that way on a db which supports foreign keys. We have all
> >sorts of bugs because we do stuff on the client.
> 
> Well, okay...  I was attempting to avoid creating some of the awkwardness
> I've had to deal with when programming for TeamTrack.  There, very few
> objects are ever actually removed from the database; instead, they get
> tagged as being "deleted".  Client code must often include clauses like
> "WHERE <whatever> AND DELETED = 0".  Nasty.  And then the interface is
> inconsistent about how it represents these tagged values.  Sometimes it just
> appends the string " (Deleted)" to them; other times it ignores them.  I'm
> hoping a reasonable alternative can be worked out here.

Well, we ahve products which are clsoed to entry. If we have views, then
we could easily and simply abstract it, but...

> >My idea was that we show them all at the end by default, but have a way
> >of the template 'knowing' which ones have been done already. That way an
> >admoin can sutomise teh templte for afield, and then it won't appear
> >with the rest of them below.
> 
> I don't follow.  How would a field have been "done" already?

Imagine that the status whiteboard and the os were custom fields, as
well as a new field called 'expected finish date'. We want all those
fields to be displayed.

The whiteboard and the os are hard coded into a position here they make
logical sense (eg os next to platform). At the end of this display, we
want to dump out all the other fields (the finish date), but we don't
want to display the os/whiteboard again.

Baicsally, we'd iterate through teh fields, and skip out those which
are already part of some hash

> >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...

> 
> >> Custom string fields may be queried in the same manner as the stock
> >> fields "Comment" and "URL".  That is, they may be matched against a
> >> user-supplied string using any of the following predicates:
> 
> >Currently, we 'allow' any of those, and rely on the db to not prseent
> >any matches. Thats not portable, so whatever we so with that will depend
> >on how we solve teh generic value/
> 
> I don't understand.  Can you elaborate?

We allow searchs for '<string-field> after <date-val>' for example, and
that just returns false in mysql.

> 
> >You left out the 'how is this stored in teh db' answer, which is the
> >important one.
> 
> That was intentional.  Again, "What" before "How".
> 

True, but you do have to remember the limitations of the db when coming
up with a design.

Bradley