Custom fields design doc

[Luis Villa]

On Sat, 2003-05-24 at 05:23, Gervase Markham wrote:
> >>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?

Just FWIW, in at least our setup, we have no need for per-product custom
fields, and if there is no way to say 'all products get this field',
it'll be quite inconvenient.

Luis (still wishing he had more time to contribute :/

> 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
> 
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=louie@ximian.com>
>