More custom field revisions

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>Sean McAfee wrote:
>> Our current incident-tracking system is administered by someone in
>> Human Resources--ie, a non-programmer.

>Wow. What do Human Resources have to do with incident tracking?

They also handle various administrative tasks.

>> Ideally I'd like for Bugzilla
>> administration to be turned over to the same person after our migration.
>> Therefore, one of my aims (which I haven't stated directly before now)
>> has been to make custom field administration as simple as possible.
>> Some groups within my company have expressed an interest in having me
>> do more advanced work, like auto-populating certain form elements based
>> on a query against a local database, but IMHO, everyday administrative
>> tasks--like renaming or rearranging fields--shouldn't require a grounding
>> in the Template Toolkit to achieve.

>One of the reasons we chose Template Toolkit is that the template 
>language is reasonably easy to learn and edit.

It was easy for me to pick up, but I was a programmer to start with.

>Also, how is rearranging the UI of your bug system an everyday 
>administrative task? :-)

Well, maybe not everyDAY, but I can easily imagine a request like "It
turns out we're using Field Z a lot more than we originally thought; please
move it up above Field C" coming up.

>> I hadn't given any
>> thought yet to how custom field form elements should be named, but surely
>> it's straightforward to name them with either the corresponding field's
>> name or its numeric ID, right?

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

Why not?

<input type="text" name="Date Received">

...OK, I just checked the HTML spec and found that CDATA attributes get
twiddled a bit:

---BEGIN QUITE---
User agents should interpret attribute values as follows:

* Replace character entities with characters,
* Ignore line feeds,
* Replace each carriage return or tab with a single space.

User agents may ignore leading and trailing white space in CDATA attribute
values (e.g., "   myval   " may be interpreted as "myval").
---END QUOTE---

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.

>And 
>naming them with a numeric ID is ugly, opaque, and inconsistent with the 
>other fields.

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.

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

>>>It's not an automatic given that the custom field will be needed on 
>>>enter_bug. In fact, an argument could be made for not including any of 
>>>them by default.

>> This seems a bit counterintuitive to me.  What is the argument for not
>> including any of them?

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

>>>Remember to display all possible custom fields if 
>>>no products are selected. :-)

>> Why?

>Because no products being selected means you are searching all products. 
>But this is the same discussion as the one above.

It had never occurred to me that one might want to search all products
at once.  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.)

>> We seem to have stumbled
>> onto a fundamental difference in our two conceptions of how custom fields
>> should work.  In my view, each product *contains* zero or more custom
>> fields, which are not shared with any other product.  There's no concept
>> of "hard linking" between products.  It may be that two different products
>> both want a date field called (say) "Date Received", and they can have them,
>> just as two distinct fields.

>I see what you are saying. But this doesn't fit with the current model, 
>where if two products have a field Foo, it's the same field (admittedly, 
>all our fields are global, but the point remains.)

>And, it makes querying much more of a pain. Imagine I had five products, 
>four of which were software and one was hardware. The software ones all 
>had a custom field for a particular purpose - frobinage level, or 
>something. In your scheme, you would have to create this custom field 
>four times, and the search page would have four different widgets for it 
>if you selected products A, B, C and D, because fields are not shared.

>A better model, in my view, is allowing a custom field to belong to any 
>number of products between 1 and N, where an N-product field is a global 
>one. This makes the querying much more intuitive, because you can select 
>A, B, C and D products, and get a single widget for querying them all 
>for frobinage level.

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

If custom fields are not shared, the administrator simply creates the
required products, then creates the fields within those products, working
down the list he was given.

If custom fields ARE shared, the administrator must search the entire list
of fields for common purpose.  For example, the set of fields { A1, B2,
F7, G3 } might all logically refer to the same thing, and so be represented
by a single custom field.  Other such sets might be { A10, B10, ..., G10 },
{ E4, G5 }, etc.  Hopefully they were assigned the same or similar names
to start with, but maybe not.

Creating a single additional product with its own custom fields would
require an intimate knowledge of every custom field in every product,
so that the new custom fields can be merged with the existing set.

Also, perhaps "frobinage level" means different things in the context of
products Foo and Bar.  If fields are shared, and names must be unique across
the entire Bugzilla installation, one of them must be renamed.

>Rephrase: why do we need multiline custom fields? (I have a sense of 
>deja vu asking this question.)

Imposing a limit of one line on custom string data seems quite arbitrary to
me.

>Related question: Do you need fine control over relative field 
>positioning?

Sure.  More important fields should show up before less important ones.


...By the way, I hope I'm not coming across like some kind of know-it-all.
My expectations for how custom fields should work is doubtlessly heavily
influenced by my experience with my company's current solution (Team
Track), which isn't really that bad, except for the speed.  (And the
price...and the closed source...and the convoluted schema...everything
except the user interface, really.)  I'm hoping to offer the users here
as seamless a transition as possible, when it happens, but I'll try to
keep an open mind about adapting to more traditional Bugzilla ways of doing
things.


-- 
Sean McAfee -- etzwane at schwag.org