Custom fields administrative interface...

[Jon Wilmoth]

For what it's worth I completely agree with the statement that BZ should
have one an only one audit mechanism.  The current mechanism works for
our use and since this custom-field enhancement is much more valuable
for our user community, I'd like to suggest that the existing mechanism
is used or enhanced.  To keep things manageable a separate defect should
be opened to track the progress of the audit changes.  The CF
enhancement would then optionally depend on that.

As for the UI administration, I agree both sides of the relationship
should support maintenance.  There is an existing enhancement
(http://bugzilla.mozilla.org/show_bug.cgi?id=209195) that would seem to
alleviate the work for ensuring new products had "global" custom fields.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Wednesday, June 11, 2003 2:18 PM
To: developers at bugzilla.org
Subject: Re: Custom fields administrative interface...

Sean McAfee wrote:
> Yes, because my responses to your suggested changes have gone
unanswered, by
> you or anyone else, since I posted them two weeks ago.  

Looking back, the current discussion thread no longer mentions the bug 
activity tracking, so that issue seems to have played itself out into 
deadlock.

As for the other one, you said:

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

This is by far from the optimum UI - I anticipate that when you create a

product, you choose which custom fields it has from a multiselect, and 
when you create a new field, you choose which products it applies to.

Merely because there is some discussion to be had on the best way of 
doing the UI for the simple-to-implement-and-understand version doesn't 
mean it should be discarded.

> As I've mentioned,
> my company is looking to transition to Bugzilla in the very near
future, and
> I can't afford to dawdle.

That may well be true; however, all of us only have a limited amount of 
time to devote to Bugzilla. Those who are paid to work on it (just 
justdave, really) have many other responsibilities.

My message is not to upbraid you for anything - it's just making you 
aware of the situation. We didn't want you to assume that silence 
equalled approval, and therefore be disappointed and surprised when, 
late on, someone came and said "well, this isn't really what we want."

>>It seems pretty clear that Bugzilla needs only one bug activity
tracking 
>>mechanism. So, for your patch to get in to Bugzilla, you either need
to 
>>provide one which replaces the current one (together with migrating 
>>code) or you need to use the current one, enhancing it as necessary.
> 
> Sigh.  Since I don't care for lossy auditing, I guess it'll have to be
the
> former.  Should I open a new bug, or what?

Why the former? You only named one bug with the latter (it doesn't 
record the entire change in a large text field).

If you want to reimplement our bug activity tracking, I guess you can 
open a new bug. But you'd need a good list of reasons why the 
reimplementation is better, and why fixing the current one isn't an
option.

And you still haven't explained what kind of use you'd have for an even 
more detailed log than the one we have. Do you trust your developers so 
little that you have to check up on their every move?

>>Secondly, the groups mechanism you are using is, in my view,
unecessary, 
>>over-complicates things and would be confusing to users.
> 
> You mean "administrators" here, right?  The grouping mechanism would
be
> invisible to ordinary users.

Users of the groups system - so yes, administrators.

>>>*  The code does not yet support multiple locales.  If we all
ultimately
>>>   agree that custom field display names belong in the database, as I
aver,
>>>   then all that is needed is a few extra joins to a new
table--cf_text,
>>>   perhaps.  Otherwise, more work is needed...
> 
>>This discussion needs to continue - but I continue to assert that my 
>>precepts stated previously remain non-negotiable. I do think there's a

>>way for us both to get what we want, though.
> 
> I'm happy to continue the discussion; the ball's in your court (or the
court
> of anyone who wants to take up a contrary position).

My suggestion is that the strings are kept in templates, but we have a 
tool for editing those templates using a prettier GUI. When it saves 
them, TT will notice and start using the new version.

Gerv

----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth@starbucks.com>