Custom fields schema
myk at mozilla.org
Tue Jan 25 22:12:43 UTC 2005
Maxwell Kanat-Alexander wrote:
>On Tue, 2005-01-25 at 07:28 +0200, Vlad Dascalu wrote:
>>I agree with Myk. The FAC proposal makes more sense for me, from all
>>points of view.
> I also used to think so.
> But if we want people to be able to write "plugins" for Bugzilla,
>Fields-As-Rows makes much more sense.
Plugins can be roughly divided into three categories:
* add no new fields (NNF), just manipulate existing ones (f.e. a
plugin that added a "checked in" comment and resolved bugs "FIXED"
when a patch on them was checked into a source control system);
* add new generic fields (NGF) that don't need to be manipulated
specially and can be implemented using custom fields;
* add new special fields (NSF) that need to be manipulated specially
and cannot be implemented using custom fields (f.e. Test Runner
Of these, only NGF plugins can use custom fields, and if a plugin just
creates a custom field and then lets the generic custom field code
handle interaction with it, then why take the trouble to make it a
plugin? It'd be much easier for installations that want the
functionality to just define the custom field themselves using whatever
interface we develop for managing custom fields.
I think very few, if any, plugins will create custom fields. But even
if some did (f.e. a plugin that created a bunch of related custom fields
which would otherwise be burdensome to create by hand via the interface,
or a plugin which reused most generic custom fields code but with a few
special tweaks), why does FAD make more sense for them? Real columns
are as easy to create programmatically, keep plugin data more separate
from standard and installation-defined custom field data, and can be
made more secure if necessary (by giving plugins a MySQL account that
only permitted write access to its own tables).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers