The Road to 2.18 - Customfields

[Joel Peshkin]

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

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, 
URL, etc...)
    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 
fields.
    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.

Comments??