Partial custom fields design document

[Joel Peshkin]

This is a very good start.

In the interest of getting the discussion rolling while Gerv isn't here 
;-), I'll respond on the list.  I think enough of the team is keen on 
seeing a good customfields implementation that this deserves this level 
of attention.  Please correct me if I am wrong.

It seems that multiple fields may wind up using the same selection id. 
 In that case, would it make sense to treat the cf_selection records as 
items that have a human-understandable name (like a typedef) so that an 
administrator who is creating 3 or 4 fields of the same type has a name 
with which to refer to that type??

I am a bit confused about as_string.  Is that supposed to be something 
that is fixed for each field type or something that is configured 
somewhere?

In either case, this should be hookable (eventually) so someone doing a 
small amount of  coding can add a function that gets called for 
conversion and validation of specific custom fields.  Similarly, other 
items that lend themselves to a degree of customization that confounds 
web configuarbility can be made hookable (after the initial patch lands).

I suspect that the system will need a notion of the length of a custom 
field and, possibly, a flag indicating if the actual contents of the 
custom field should be logged in the activity log and if it should be 
included in bugmail.

One additional schema change is probably needed.  I suggest that 
bugs_activity have a new field that distinguishes between schema fields 
(references to fielddefs) and custom fields.

There is probably enough information in the schema to make boolean 
searches work.  A subsequent enhancment can make the fields more 
casually searchable.

-Joel