New custom fields proposal

[Bradley Baetz]

On Fri, Apr 04, 2003 at 08:33:38PM -0500, Sean McAfee wrote:
> Hi, folks--
> 
> Enclosed is my proposal for new custom field functionality to be added to
> Bugzilla.  Please read, discuss, criticize, etc., especially the "Open
> questions".
> 

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

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

> 
> Integer
> -------
> 
> An integer custom field contains values which are integers.  Such
> fields must be able to store at least the range of integers which are
> typically represented as a signed four-byte quantity.
> 
> [Open question: Should integer fields be available in signed and
> unsigned varieties?]

Should be fine - its just a check on entry, really.

> 
> 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 don't see much use for integer
(or float) custfields in any event - what sort of use do you have
anyway?

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

> Float
> -----
> 

<snip> This is all fine, but what sort of stuff do you expect people to
have custom floats for?

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

> Each string field is flagged as belonging to one of two varieties:
> short and long.  A short string field can hold a maximum of 255
> characters, and may contain no vertical whitespace characters
> (carriage return, newline, or vertical tab).  It is represented on
> Bugzilla's Web interface using a single-line text form element.  A
> long string field can hold large amounts of text, possibly consisting
> of several lines.  It is represented on Bugzilla's Web interface as a
> multiline textarea form element.
> 

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

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

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

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

> It is
> represented on Bugzilla's web interface as a drop-down listbox form
> element.  A multiselection field's value is an arbitrary subset of the
> field's possible values.  It is represented on Bugzilla's web
> interface as a multiline listbox in which multiple simultaneous
> selections are allowed.
> 

Technically, its represented as <select> and <select multiple> :)

> 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.
> 
> Since such queries may be expensive, Bugzilla may cache the results
> for up to one hour.

What do you do when the remote db drops an entry which you ahve values
for?

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

> 
> It should be possible to share the definitions of selection fields
> among multiple Bugzilla components, such that a change to one field's
> data source is reflected in all other fields which share that source.

Again, s/components/products/

We can do like what we do for flags, but I';m worried about perf if we
have to do it in perl, without subselects.

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

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

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

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

Good.

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

> Custom multiselection selection fields may be queried against a
> multiline listbox containing all valid values for the fields.
> Multiple selections within this listbox are allowed.  A pair of
> radiobuttons is placed next to the listbox which present two choices:
> "Any" and "All".  Initially, "Any" is selected.  If the "Any" button
> is selected at the time the query is initiated, then a bug matches
> this query term if any of the selected values are set in this field.
> If the "All" button is selected instead, then a bug matches this query
> term if all of the selected values are set in this field.

I'm not sure about this. attachments/cc/etc are a bit strange surrently
with the search stuff.

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

Bradley