More custom field revisions

[Jon Wilmoth]

Sean McAfee wrote:
> Here are some additional revisions.  

> A Date field describes a particular moment of time.  It is represented
> on Bugzilla's web interface as a single-line text form element.

I don't think you should specify this explicitly. It should be possible 
to have a variety of representations for Date fields - i.e. you do
[% INCLUDE date_field date = "10035356674" type="date-time" %]
or similar and the template defines the representation.

I think this is fine for a default...just so long as the implementation doesn't prohibit the template from defining the representation.

> Each Date field is flagged as belonging to one of two varieties:
> date-only and date/time.  A date-only Date field is represented using
> the format 'YYYY-MM-DD'; a date/time Date field is represented using
> the format 'YYYY-MM-DD HH24:MM:SS'.  (Arbitrary whitespace may
> separate the two components in the latter case.)  When a user enters
> text into a Date form element, it must conform to the appropriate
> format, or Bugzilla will signal an error condition.

I think that dates should always be displayed as above, but dates should 
be able to be input in any format which can be unambiguously understood 
by Date::Parse. Let's not enforce restrictions we don't need.

Obviously there needs to be some validation to ensure the string representation can be understood by Date::Parse.  I'd like to propose the following:

Add additional BZ params, "dateFormat", "dateTimeFormat" that define the format for all dates input into the system.  To aid users, the templates could/should display the input format near the input field.  This also allows for a common rendering technique for date values.  Furthermore, it aids localization.

> A multiselection field's value is an arbitrary subset of the field's
> value set.  It is represented on Bugzilla's web interface as a
> multiline listbox in which multiple simultaneous selections are
> allowed.  The listbox's vertical size is equal to the value set's size
> or five, whichever is smaller.

The current ones on query.cgi are 7, which seems like a nice size to me. 
  And they are all the same size even if some have less than seven 
elements, which looks better. But this is a minor display issue.

I agree that the consistency of the multi-select fields adds to the aesthetics of the tool.

> Whenever a user edits a bug and changes one or more custom fields, the
> changes must be logged. 
<snip>

Are all these requirements met by the existing Bug Activity system?

> On "enter_bug.cgi" and "long_list.cgi", the custom fields will be
> shown just after the "Description" text box.

It's not an automatic given that the custom field will be needed on 
enter_bug. In fact, an argument could be made for not including any of 
them by default.

Agreed.  Our user's appreciate the less is more theory.  However, this could be addressed by assigning the field to a group and wrapping the display in isUserInGroup('') block.

> Different projects may define different custom fields with the same
> name.

No; this is an error. That's fine, because the display name is separated 
from the internal name. They could define the same display name for two 
fields, but any confusion caused is their fault :-)

Hmm... there's a bit of info missing in my mind. Is it possible to have 
a custom field which is part of projects A, B and C but not D or E?

Yes!  I intend to have several products (i.e. A,B,C and D), which have one group of people for accountability, share one or more custom fields (i.e. need by date).  Other products (i.e. E,F and G), with accountability belonging to another group, may not have a "need by date", but may have a common "test lab" field.

> Custom fields in the
> global scope (if any) are grouped together under the italicized label
> "Global fields"

No need for that; they should be treated like any other hard-coded 
field, and not singled out for special attention.

Agreed for the default, this will reduce unnecessary UI complication.  However, I could see the "custom field" object exposing the scope through a variable to the template so people that wanted to differentiate could.  For example:

[% IF custom_field.global == 'true' %]
	<i>Custom Field Label</i>
[% END %]


> Administration
> ==============

> Editing a custom field
> ----------------------
> 
> The only aspect of a string, integer, and date field that may be
> edited (other than its name, handled by a separate Rename operation)
> is its default value.

And which products it belongs to?

> For a new String field, the first page presented includes only a pair
> of radiobuttons, labelled "Long string (multiline, up to 64K
> characters)" 

Remind me again why we need this long string type?

Text Area vs. Text box fields

> [Open question: Since this is such a potentially damaging operation,
> maybe it should not be available via the web interface at all.
> Perhaps the administrator should be required to run, from the command
> line, a special program provided for this purpose.  Or perhaps deleted
> field data should be retained for a time to make an undo operation
> possible.]

Normally, we allow people to shoot themselves in the foot if they like. 
:-) But perhaps you are right; this might need to be a command-line 
operation.

At the very least, it should come up in a Sanity Check as an error.