Custom fields design doc

Wed May 28 02:46:23 UTC 2003

Gervase Markham <gerv at mozilla.org> wrote:
>> It's my proposed mechanism for implementing field sharing.  Say a group
>> G contains fields Foo, Bar, and Baz.  Then every project that contains the
>> group G also has fields Foo, Bar, and Baz.  I probably didn't describe the
>> concept in enough detail, but I hoped the editcustomfields.html example page
>> I provided would get the idea across.
>
>I'm not sure that the groups are really necessary... why not just have a 
>mapping from custom field IDs to product IDs?
>
>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.

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.

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.

>>>>cf_selections
>>>>-------------
>>>>
>>>>cf_selection_labels
>>>>-------------------
>> 
>>>Why can these two tables not be combined?
>> 
>> Because then the unset_label column would have to be duplicated.

>E.g. in the cf_selection_labels table, if the label_index was 0, or -1, 
>or whatever special value you want, then that would be the unset_label. 

I was designing defensively, letting the sole meaning of label_index be
in its value relative to the indices of other labels of the same field.
It's my expectation that the indices will always be in the range 1 .. N,
but I wanted to leave the door open for other schemes.

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

<select name="selection_field">
  <option value=""> </option>
  <option value="Foo">Foo</option>
  <option value="Bar">Bar</option>
</select>

I wouldn't find that particularly intuitive.

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

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

>> Finally, the current activity table (bugs_activity) logs
>> changes in tinytext columns, which aren't big enough to log changes in
>> long string fields or some multiselect fields.  Even if the columns were
>> widened to the text type, multiselect changes could potentially still be too
>> large for them, as I've described in a previous message.

>The bugs_activity log is for auditing rather than rollback, and so it's 
>not completely essential that it capture all changes, or all parts of a 
>particular change. For example, it doesn't currently capture added 
>comments.

I had accurate auditing in mind, not rollback.

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

>>>>ADMINISTRATION
>>>>==============
>>>>Each page contains a single form, which always contains a hidden field
>>>>called "context".
>> 
>>>We call this "action" everywhere else.
>> 
>> "context" is more intuitive to me, but oh well, viva consistency.
>
>(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.

>>>What is a scope?
>> 
>> A project, a group, or the global scope.
>
>What's a project?

Sorry, I slipped back into my Teamshare vocabulary there.
Project == Product.

>> 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?  Each should be able to independently do his
job solely from the design doc, but this would be impossible without
fixed keys.

-- 
Sean McAfee -- etzwane at schwag.org