More custom field revisions

[Gervase Markham]

>>They can't be named with the name if the name contains spaces.

OK, that was rubbish. But the argument from consistency still holds.

> I had already disallowed carriage returns, line feeds, and leading and
> trailing whitespace.  The tab conversion is a problem, but it can be solved
> by the reasonable step of disallowing tab characters in field names.

The other thing is that people often read Bugzilla URLs. As spaces get 
encoded as %20, using them in field names makes them much harder to read.

query.cgi?Wibble%20Fish=Something&%3FFoo%20Field%41=Something%20Else
c.f.:
query.cgi?product=Something&component=Something%20Else

> Ugly and opaque, perhaps.  I wasn't so worried about inconsistency, since I
> had envisioned custom fields as a different kind of beast than the standard
> fields.

We have to get away from this idea, then :-)

Principle: Custom fields should appear to the user, as much as possible, 
in the same way as non-custom fields. If a field stopped being 
hard-coded and started being global custom, they should not notice.

Principle: Custom fields should use and leverage as many of the existing 
Bugzilla mechanisms for doing things as possible. E.g. bug change tracking.

>>All of our fields have well-known alphabetic identifiers (bug_status, 
>>qa_contact, bug_file_loc) which are used to refer to that field through 
>>the code and in forms. The custom fields should not be an exception to 
>>this rule.
> 
> I'm not so concerned with breaking this rule, since custom fields are by
> their very nature site-specific and nonstandard.

"Well-known" also means well-known within a site. And see above thoughts 
about URL readability.

>>Our current enter_bug page (the normal one, not format=guided) doesn't 
>>include several of the more advanced fields, on the basis that bug entry 
>>should be a reasonably low barrier-to-entry process.
> 
> That's probably true for most Bugzilla installations, but the one I intend
> to set up here will be strictly internal to the company and used only by
> people who are very familiar with the products they'll be using.
> 
> Perhaps a sitewide parameter always_show_all_custom_fields or somesuch?

Let's not dodge the issue with a pref - anyway, it's a display issue, so 
people should edit templates to move away from the default.

I can see the conflicting demands here. Let's start by including them; I 
suppose people can comment out the generating code in the templates if 
necessary.

  > It had never occurred to me that one might want to search all products
> at once.  

Trust me, it happens a lot. For example, on b.m.o., people commonly 
search in both Browser and MailNews. Or on all products at once if they 
are lazy.

> A product represents one particular class of incidents, which
> doesn't necessarily have anything in common with any other class of
> incidents, right?  (Except, necessarily, the fixed, global fields.)

It doesn't _necessarily_, but it may well.

> Imagine this scenario.  A company is ready to bring its new Bugzilla
> installation on-line.  Some group has come up with a list of ten products
> (call them "A" through "J") each of which will require ten custom fields
> ("A1" through "A10", "B1" through "B10", etc).

I think Chris Hicks has replied to this well. I'll comment on what he says.

> ...By the way, I hope I'm not coming across like some kind of know-it-all.

Not at all. I think you're engaging in this debate in an exemplary 
fashion :-)

Gerv