More custom field revisions

Sean McAfee etzwane at
Tue Apr 29 23:58:39 UTC 2003

OK, so the picture I'm getting is this:

-  When many products are related, it's better that custom fields be
-  When products are mostly or entirely isolated from one another, it's
   better that custom fields be unshared.

So, is there any way to make everybody happy?  Well, here are some

It appears that what proponents of shared custom fields are describing is
similar to my own concept of global custom fields.  One approach, then,
might be to keep my proposal mostly intact, but to additionally give
global custom fields the semantics suggested by shared-field proponents,
including the unique alphanumeric identifier.

Another approach might be to flag each product as "open" or "closed".
Open products share all of their fields with all other open products;
closed products don't share their fields at all.  Each site could set
its own default value for this flag.

A generalization of the previous approach would be to allow products to
be grouped together.  Every product within a group would share the same
custom fields.  Groups would necessarily be disjoint, and there would
be no special global scope.

Approaching from the opposite direction, perhaps custom fields could
be arranged into named groups.  Someone previously cited an example of
a Bugzilla installation with four software-related products and one
hardware-related product; the software products shared many fields,
and one would often want to search one or more of these fields without
needing to duplicate search terms.  Suppose, then, that one could create
a field group called "sw-fields", with members like "Library Version",
"Compiler", "Delivery Date", etc, and then include this group into each
of the software products.  One could even give each product some private
fields as well:

Product Foo      Product Bar      Product Baz      Product Bletch
-----------      -----------      -----------      --------------
group:sw-fields  group:sw-fields  group:sw-fields  group:sw-fields  
Foo Field 1      Bar Field 1                       Bletch Field 1
Foo Field 2

If Product Bletch were related to the hardware product in some way,
another group called "hw-fields" could be created, and exported into
both products--or, more likely, hw-fields would be created as a subset
of the hardware product's fields, and then exported into Bletch.

I'm starting to like this last approach more and more, although it does
introduce a nontrivial amount of complexity.

Any opinions?

Sean McAfee -- etzwane at

More information about the developers mailing list