Custom fields administrative interface...

[Gervase Markham]

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