Custom fields design doc

[Gervase Markham]

>>I'm having trouble understanding this proposal, because of one big 
>>question: what's a custom field group?
> 
> 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.

>>"display_index" should have the same name as the fields which do the 
>>same thing in other tables (can't remember what it is offhand.)
> 
> Would that be "sortkey"?

Yep :-)

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

>>>The following six tables hold bug activity data.
> 
>>Dude, scrap this! Use our current tables for bug activity data. Please! 
>>:-) Store the name of the field, what it changed from, and what it 
>>changed to, just like now. That's fine. Really.
> 
> 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.

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

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

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

>>>Initial page
>>>------------
>>>Context:  choose-scope
>>>Template: template/en/default/custom/choose-scope.html.tmpl
>>>
>>>The user may select a scope via either of the following three elements:
> 
>>What is a scope?
> 
> A project, a group, or the global scope.

What's a project?

> 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 :-) I wouldn't deny that implementing it gives 
you good ideas about implementation, but if you change the actual 
_design_ for technical reasons, there's usually something wrong (unless 
what you wanted is genuinely impossible.)

Gerv