More custom field revisions

[Gervase Markham]

Sean McAfee wrote:
> And when you later create product N+1, and want it to have the same
> "global" fields as the original N products, do you need to remember which
> fields you'd previously added to the first N and add them individually
> to N+1?

It's a reasonable point, but doesn't destroy the model. There's two ways 
you could play this:

- Say that you have to allocate custom fields by hand for each new 
product, because there's no way Bugzilla can know which one you want

- Have the product selection UI phrased as "Restrict to products:" and 
differentiate between the cases where the admin selects all N (which 
would restrict the field to just those N unless changed manually) and 
where the admin selects none at all (which would mean the field was 
auto-added to each new product.) This would require a "global" boolean 
in the database; but it would only be looked at when doing admin - the 
implementation would still be common.

> What concerns me is the spectre of a set of N products on the one side,
> a set of M custom fields on the other (N and M both being large), and
> some arbitrarily complicated set of has-a relationships between them.

You make it sound complex, but it's not. On every "edit custom field" 
screen, you have a "Restrict to products:" multiselect. And that's all 
you need.

> OK, I can see the utility in this.  I would ask, though, that the
> administrator not be required to compose from scratch, for every field,
> a name which isn't relevant to the user interface. 

Again, you make it sound complicated. I suppose it depends on whether we 
define the display names in the templates (which I think we should, but 
I'm open to persuasion) but the UI could be something like this

short name (lower-case alphanumeric and underscore): [        ]
display name:  [           ]

> The admin interface
> could, for example, propose a reasonable default by downcasing the
> display name and replacing all nonalphanumerics with underscores, and
> twiddling the result to avoid name collision.  The administrator could
> then accept this suggestion, modify it, or nuke it and make up a new one.

Hmm. We could do that. If it were me, I'd like to pick my own, but I can 
see the value in Bugzilla making a suggestion.

>>- The separation of content from presentation by moving the definition 
>>of how and where the fields are displayed to the templates.
> 
> I think it should be possible to modify the presentation of custom fields in
> this way, but I'd rather provide reasonable default behavior that obviates
> the need to perform template-twiddling for each and every custom field.

Oh, I agree that we should display them without intervention - note that 
I said "how and where", not "if" :-) In other words, there should be a 
default location, and changing it requires hacking templates, plus a 
default UI widget, and changing that requires hacking templates.

So your suggestion of how to do it sounds roughly right. :-)

Gerv