More custom field revisions
gerv at mozilla.org
Wed Apr 30 07:52:41 UTC 2003
>>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.
> 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
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
> 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
> 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
> 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
More information about the developers