More custom field revisions

[Gervase Markham]

Jon Wilmoth wrote:
> > 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.

Er... Date::Parse would attempt to understand the string, and we'd throw 
an error if it failed, just like we do for invalid input of any other sort.

> I'd like to propose
> the following:
> 
> Add additional BZ params, "dateFormat", "dateTimeFormat" that define
> the format for all dates input into the system.  

Why restrict users to one date format?

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

<cough>

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

As I've said elsewhere, I am not convinced that we need a mechanism any 
more complex than 'insiders' for restricting bug data on a per-field 
basis. Fear unnecessary complexity. :-)

But, even if we accept the premise, how does it solve the issue I raise? 
My point was that we should not have any mechanism for displaying custom 
fields on the bug entry page. Admins could add them to the templates by 
hand if they want them (after enter_bug and process_bug unite.)

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

Right, fine. But then it should definitely be an error to have two 
custom fields with the same internal name.

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

<cough> :-)

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

Remind me again why we need fields which are textareas, but which aren't 
comments? I can't think of a use for them.

Gerv