More custom field revisions

[Gervase Markham]

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?

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

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

If by renaming fields you mean changing the UI label on them, then again 
that shouldn't happen very often, but also it should merely be changing 
the relevant text string in a template. Even if it's surrounded by 
incomprehensible gibberish, I think most people could manage that.

And, if they can't, you could write some scripts to help them out.

> My design doesn't call for any database entities (tables or columns)
> to share names with fields, so that reason's moot.  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. And 
naming them with a numeric ID is ugly, opaque, and inconsistent with the 
other 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.

>>Did we decide to leave Email Address until version 2?
> 
> It was only mentioned once, briefly, that I recall.  Would this be a
> string-like field that is checked for RFC822 validity when submitted,
> or one which offers a choice of all known users?

It would be a string-like field which is checked for being a valid user 
email address (in the same way as e.g. QA Contact is), and who is 
emailed (according to preference settings) when there are any changes to 
the bug. But feel free to leave this until version 2.

>>Are all these requirements met by the existing Bug Activity system?
> 
> I hadn't considered the existing system, since I've been attempting to keep
> the custom field implementation as orthogonal as possible to the core.  Are
> you suggesting that the existing activity system could be leveraged to hold
> custom field activity data?

I would be surprised if any other course of action was considered! :-) 
If I ask for bug activity in the UI, I want it all. The user doesn't 
care how particular fields are implemented. And if I'm implementing the 
bug activity page, I don't want to have to query two sets of tables and 
merge the data.

Have a look at the existing bug activity system; it may require a small 
amount of enhancement to meet your needs. Don't be afraid to not 
reinvent the wheel :-)

>>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. In addition, we 
have "bug entry templates" (see the manual) which is a way of asking for 
structured information to be formatted into the comment. This is, in my 
view, all you need to enter a basic bug report.

Optionally, we could make it possible to add UI for individual custom 
fields to the entry templates by hand, but I don't think that displaying 
all of them by default is the right way to go.

(In the long term, the bug entry and bug editing processes will be 
unified, and then you'll have total freedom about what fields to include.)

>>>Here is an alternate approach.  Global custom fields are always
>>>displayed.  A button is to be added to the query page, to the right of
>>>the "Product", "Component", and "Version" listboxes, labelled "Show
>>>custom fields for these projects".  If the user clicks it, the query
>>>form is redisplayed, augmented with all custom fields in all of the
>>>selected projects.  
> 
>>_Any_ of the selected projects?
> 
> Er, no.  All of them.

So if you select products A, B, and C, and custom field Q is only 
available in Products A and B, it doesn't appear?

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

>>>When custom fields are being shown, a second button is to be added
>>>below the "Show custom fields" button, labelled "Hide custom fields".
>>>When it is clicked, the query page is redisplayed as it was
>>>originally, showing only custom fields in the global scope (if any).
>> 
>>Why is this needed? They can always just ignore them.
> 
> Because there may be a lot of fields, and they may be distracting.

Well, the user pressed the button to display them in the first place! 
And they can always reload the page, or select different products and 
re-show, if it really bugs them.

>>Hmm... there's a bit of info missing in my mind. Is it possible to have 
>>a custom field which is part of projects A, B and C but not D or E?
> 
> Definitely not, at least according to my proposal.  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.

>>>For a new String field, the first page presented includes only a pair
>>>of radiobuttons, labelled "Long string (multiline, up to 64K
>>>characters)" 
> 
>>Remind me again why we need this long string type?
> 
> 
> First, to provide two different form elements, single-line and multiline.

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

> Second, because I can easily imagine needing to enter a detailed report of
> some kind that could run over 255 characters.  I occasionally do so with my
> company's current issue-tracking system.

Into a custom field, as opposed to into a comment or a new bug?

>>What does this ordering affect? If it's display ordering, this is the 
>>wrong place for it - such configuration belongs in templates.
> 
> Templates are static; field ordering is dynamic. 

Related question: Do you need fine control over relative field 
positioning? Take our current bug UI - does it really matter if Priority 
is above or below Severity, as long as it's consistent from product to 
product?

> I can't think of any
> way of putting field ordering into a template that isn't clearly the
> Wrong Thing. 

Discussing this issue will probably make more sense after we've resolved 
the products-sharing-fields issue.

> Yeah, maybe so.  A MySQL enum would be good here, but I seem to recall
> reading somewhere that developers are supposed to avoid MySQL-specific
> features to make it easier to port Bugzilla to other databases in the
> future.  Is this right?

Indeed :-)

Gerv