Custom fields design doc

[Gervase Markham]

Sean McAfee wrote:
> Gervase Markham <gerv at mozilla.org> wrote:
>>The UI would be something like:
>>
>>Product: Foo-Bar Product
>>
>>Choose the custom fields for this product:
>>
>>|------------|
>>| SomeField  |
>>| OtherField |
>>| Priority   |   <- multi-select list box
>>| Severity   |
>>| Chip Name  |
>>|------------|
>>
>>This seems, conceptually and in code, the easiest thing.
> 
> My objections:
> 
> 1.  Lack of context.  The administrator could easily add the wrong field
> if its name is similar to that of the desired field.

Then don't give your fields similar names. :-) That's like saying "A bug 
filer could accidentally choose the wrong product if you give them 
similar names." - "Well, don't do that, then :-)"

> 2.  This interface provides no high-level view of the relationship
> between products and fields.  Suppose an administrator wants to change
> some property of a field Foo.  The admin won't be able to know which
> products the change will affect without examining the field list for
> every product in the installation.

I didn't define the sum total of the interface to custom fields, merely 
the one under question. I anticipate that, on the screen for altering 
the properties of a particular field, it would list which products it is 
currently used by. It might even let you change them there too, so you 
could attack the mapping from either angle.

> 3.  I think it'll be more common than not that fields will be shared
> in related groups.  Suppose ten products share ten related fields.
> To add a single new related field to each product, or to remove one of
> the existing fields, would require ten separate operations under your
> scheme, but only one under mine.

Assuming for the moment that your assertion about grouping being common 
is correct, this might, then, take an admin one or two minutes instead 
of five seconds. Is that worth the extra complexity (both UI and code) 
introduced by field groups, given that adding new fields would not (or 
definitely should not!) be an every day activity?

In addition, the UI for defining a new field would probably have a 
multi-select which allowed you to define the initial products it was a 
member of. So it wouldn't take even two minutes unless you added it later.

I'm happy to do a complete UI design for the admin interface to custom 
fields, if that'll help clear up any ambiguities.

>>But actually, I don't really see the need for an unset_label at all. 
>>What's wrong with "the field should be blank if it's not been set".
> 
> How then does the user unset a single-selection field?  With a blank
> selection option?

It depends what you mean by "unset". If the admin wants to allow a "none 
of the above" option, they'll add one, calling it "", "<none>", or 
whatever they like.

They may, however, want to make it so that this field always has one of 
the set values (i.e. it's compulsory on bug filing, and can never be 
unset.) This can't be done if there's an ever-present unset value.

The provision of a blank, none-of-the-above or unset value should be up 
to the admin, not us.

>>>I'm reluctant to do this for a few reasons.  First, the more orthogonal
>>>the custom fields implementation is to the core, the less chance there
>>>is of a buggy interaction between the two.
> 
>>The more tested core code the custom fields implementation reuses, the 
>>less buggy it will be :-)
>>
>>Do not think of custom fields as some sort of side bolt-on that can be 
>>unbolted later.
> 
> I wasn't thinking of unbolting, but of modularity, which has many well-known
> benefits.

As does code reuse :-)

>>>Second, queries against bug
>>>activity would be complicated by cast functions if everything is stored
>>>as a string.  
> 
>>I don't quite understand this statement. What problem is is highlighting 
>>that we don't currently have anyway?
> 
> Well, I don't know all of the current problems, so I can't answer this.
> I'd just think it's cleaner to have where clauses like
> "WHERE new_value > 20030101" rather than
> "WHERE CAST(added AS DATETIME) > 20030101".  Come to think of it, it's
> impossible to unambiguously disinguish stringified selection field
> changes if some of the possible values are alike at the beginning or end.
> For example, if a selection field's domain was "FOO", "BAR", and "FOO BAR",
> and the string "FOO BAR" was stored in bugs_activity's "added" column, does
> that mean the single value "FOO BAR" was added, or the two values "FOO" and
> "BAR"?

I believe that (for the only multi-valued field we have, CC list) the 
field separator is a comma. But I'd have to check.

>>I agree that this needs discussion, but truncating the stored parts of 
>>long string changes or multi-select changes to tinytexts might well be 
>>an acceptable solution. Expanding the field size might also be fine.
> 
> I'm reluctant to accept lossy auditing.

Then upgrade the current bugs_activity system. But no-one has ever 
complained about it before. What exactly do you plan to audit that would 
require such detail?

>>(This assumes, of course, that I understand what this field does. Does 
>>it define what action the CGI takes when the form is submitted?)
> 
> No, it describes the page from which editcustomfields.cgi was invoked.  It's
> "main-menu" on the main menu, "create-field" from any of the field-creation
> pages, etc.  In the main-menu case, I use the "action" parameter to identify
> which submit control was pressed, like so:
> 
> <input type="hidden" name="context" value="main-menu">
> <input type="submit" name="action" value="Move"> a custom field.
> <input type="submit" name="action" value="Edit"> a custom field.
> <!-- and so on -->

Right. So why do you need both "action" and "context"? Surely a single 
parameter, defining what is actually to be done, is sufficient?

>>>As just one example, in theory
>>>it's sufficient to copy the "type" column from the custom_fields table
>>>into a template-accessible hash, but in writing the template I found
>>>that it's clearer to abstract the type information into several distinct
>>>members--"is_integer", "is_string", etc.  
> 
>>This sort of decision is also implementation, and has no place in a 
>>design document either :-)
> 
> You seem to be saying that no Perl-related design document should
> ever decide what names to use as hash keys.  I disagree.  In this case
> particularly, the keys are a crucial part of the interface between code
> and template.  What if one person were assigned to implement the code,
> and another the templates?  

I'd say that you don't implement from a high-level design (which this 
is.) You implement from a low-level design or an API specification (e.g. 
hash key names.) If this document is going to eventually define 
everything you'd need to know to implement the function, then we'll be 
here all year :-) But perhaps this is getting off-topic.

Gerv