Partial custom fields design document
bugreport at peshkin.net
Fri Mar 12 03:26:52 UTC 2004
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
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
More information about the developers