More custom field revisions

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>Sean McAfee wrote:
>> 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, that approach addresses the issue, but it doesn't scale well.
Adding a new global field to an N-product installation would involve:

1.  Shift-click all products visible in the multiselect (seven, say).
2.  Scroll down.
3.  Repeat steps 1 and 2 (ceil(N/7)-1) times.

If a new field were to be shared by only half the products, the admin
would have to scroll down the entire box, carefully shift-clicking the
correct half.  I see significant room for input errors.

If named field groups were employed instead, the previous two situations
are more straightforward to handle.  I think it's worth shouldering some
additional complexity to provide a cleaner, more intuitive interface.

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

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

I'm not really comfortable publicly exposing what is essentially an
implementation detail, of relevance only to those who sling around
query URLs.  This may be my own divergent experience again, but that's
not really common practice here.

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

But you've also said that display names should reside in templates,
so the simple act of defining a new custom field would require hacking
templates (for small values of "hack").

-- 
Sean McAfee -- etzwane at schwag.org