The Road to 2.18 - Customfields
bugreport at peshkin.net
Sun Mar 14 16:26:10 UTC 2004
Bradley Baetz wrote:
>Yes! Any custom fields solution must be able to do that. Not
>necessarily for the first round of patches which goes in, but the
>implementation must not prclude that happening in the future. (QA
>contact is a bit tricker because it needs email hooks, but status
>whiteboard and target milestone/version should be trivialy doable.)
So, if I focus on the bugs table itself, fields might fit into several
1) "Core" fields that are integral to the way bugzilla itself operates.
(Examples: bug_id, assigned_to, etc...)
These would probably never become customfields, but some of the
functions invented to handle customfields may be useful in handling these.
2) "Traditional" fields are fields that would have been customfields,
but BMO and others needed them when customfields did not exist, so
everyone has them and many sites use them. (Examples: status_whiteboard,
These could eventually become customfields if the functions invented
to handle customfields, combined with hooks and template support, permit
them to work just as well as they do now.
3) "Customfields" are the fields about which we have been debating.
4) "Site" fields are fields that have been hacked into sites by folks
who needed them badly enough to patch them into checksetup, Search.pm,
their templates, etc...
If we decide to keep the customfields in the bugs table and have
other tables that describe the presentation and proper handling of
customfields, it should be possible to "adopt" a site field with the
same mechanism as customfields and make it unnecessary for a site to
maintain their old hacked code going forward while still keeping the data.
With this in mind, I suggest the following view...
a) Field definition of customfields be handled by editing "cf_config"
and running checksetup. When a field is defined in cf_config, it should
be added only if it previously did not exist. cf_config should prepend
"cf_" to the field names of all new fields it creates, but it should
permit a field without the "cf_" prefix to be specified for pre-existing
The information in cf_config should permit a field to be defined
(like AddField and AddFDef did) as well as permitting additional indices
to be defined.
b) Once fields are defined and created by running checksetup, the
web-based tools for handling customfields (hopefully very similar to
those already done in the customfields patch) can be used to define how
those fields are presented and used.
c) Template authors should always be able to define a "hook" indicating
to the automatic customfields presentation code that the template wants
the automatic customfields code to omit a field and leave it to the
template code to handle it. Standard templates could use this to
continue to handle status_whiteboard and URL fields. Custom templates
could use this to handle custom fields in any manner they choose. It
probably makes sense to permit this hook to be processed on a
per-template basis so that a site could use the automatic presentation
of a field on a bug entry form while overriding that with a custom
presentation on the "format for printing" page.
More information about the developers