New custom fields proposal

[Sean McAfee]

Bradley Baetz <bbaetz at acm.org> wrote:
>On Fri, Apr 04, 2003 at 08:33:38PM -0500, Sean McAfee wrote:
>> 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".

>I thought we were only going to do per-product? Everything else is
>per product.
>
>Per component is a pain, because it means that we have to handle the
>'what happens when you move a bug between components' case which we sort
>of fudge ATM.

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?

>> Custom fields will be available in five major varieties: integer,
>> float, string, date, and selection.  The first four of these types are
>> collectively referred to as "scalar" types.  All scalar fields can be
>> set to a special "undefined" value in additional to the valid values
>> described below.

>How are you planning on storing those in the db?

I hadn't determined that yet.  Still working out the "What" before attacking
the "How".

>> Bugzilla should signal an error condition if a user attempts to store
>> an integer outside of the allowed range into an integer field.
>> 
>> [Open question: Should Bugzilla transparently offer large-integer
>> semantics?]

>I don't think theres a need.

I agree.

>I don't see much use for integer
>(or float) custfields in any event - what sort of use do you have
>anyway?

I included the two numeric types mainly because our existing system
(TeamTrack) offers them.  I suppose it wouldn't break my heart if Bugzilla
didn't have them.  The vast majority of our TeamTrack custom fields are of
the String and Selection variety, the rest being mostly Dates.

Anyone else have an opinion?

>> Bugzilla may emit client-side scripting code onto any pages that
>> request custom-field input that will abort form submission if an
>> integer field's submitted value is out of range.

>Thats a separate bug. Don't put too much into this, or it'll never get
>done.

Check.

>> String
>> ------
>> 
>> This type of field contains human-readable text.
>> 
>> [Open question: Should Bugzilla reject attempts to store arbitrary
>> binary data in a string field?]

>UTF8 only.

Sounds reasonable.

>> Date
>> ----
>> 
>> A date field contains either a date (ie, a specific day of a specific
>> month in a specific year), a time of day (ie, an hour from 0-23
>> inclusive, and a minute and second, both from 0-59 inclusive), or
>> both.  Each date field is flagged as containing one of these three
>> subsets of data.
>> 
>> [Open question:  Is the "time of day" subtype really necessary?]

>Again, start of simple. What would people want to have a time of day
>for? Just a date...

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.

>> Date fields are represented on Bugzilla's web interface using a pair
>> of drop-down listbox form elements (for the month and day) and a
>> single-line text-entry element (for the year) for the date portion of
>> the field's value (if appropriate), and a single-line text entry
>> widget for the time portion (if appropriate).  Bugzilla should signal
>> an error if an invalid date or time is submitted.
>> 
>> [Open question: Is this too busy?  Should a simple text-entry widget
>> suffice for all date types?]

>To start with, yes. Adding a calendar popup can be a separate bug.

Okay, that's fine.

>> 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?]

>No limit. People can set however many entries they want. If they hve
>several thousand, then its their problem.

Sounds reasonable.

>> Each selection field comes in one of two varieties: "single-selection"
>> and "multiselection".  A single-selection field's value is a subset of
>> the field's possible values of size either zero or one.

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

>> Each selection field's set of allowed values may be specified in one
>> of two ways.  A "local" selection field's values are defined by the
>> Bugzilla administrator, and are managed by Bugzilla itself.  A
>> "remote" selection field's values are taken from a table in a database
>> which need not be the same database used by Bugzilla.

>Thats very complex.... Lose it for the first round, I think.

Okay.

>> Since any given selection field's allowed values may change over time,
>> due to administrator action or variation in a remote data source,
>> Bugzilla should not signal an error if "invalid" field values are
>> found in the database.  Enforcement of a selection field's valid
>> values is to be done only on the client side.  If a bug containing a
>> selection field whose value is no longer valid is edited by the user,
>> the invalid field's value should be presented as being the null set.

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

>> Logging
>> =======
>> 
>> Whenever a custom field's value is changed, this change should be
>> logged.  Log information should include the identity of the user who
>> made the change, the time the change took place, the field's old
>> value, and the field's new value.

>This is the activity log, right?

Precisely.

>> Presentation
>> ============
>> 
>> Custom fields are to be presented on each Bugzilla page that presents
>> the standard Bugzilla fields.  These pages include at least the
>> following:

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

>> The query.cgi page requires more extensive modifications.
>> 
>> Here is an alternate approach.  A button is to be added to the query
>> page, to the right of the "Product", "Component", and "Version"
>> listboxes, labelled "Show custom fields for these components".  If the
>> user clicks it, the query form is redisplayed, augmented with all
>> custom fields in all of the selected components.  If no components
>> were selected, or if no selected component has any custom fields, the
>> page is simply redisplayed as it was before.

>Again, this is why it should be per product. Why not just show them all?
>We show all teh target milestones, after all (and the UI should be able
>to combine entries in some way, where teh field is the same but the
>values are different)
>
>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?

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

>You left out the 'how is this stored in teh db' answer, which is the
>important one.

That was intentional.  Again, "What" before "How".


--Sean