Custom fields administrative interface...

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>Sean,
>I haven't had (and may not have for a while) time to evaluate this 
>particularly closely. Keeping up with all of this is a time-sink - and 
>other Bugzilla hackers have noticed that, which is why your proposal has 
>not yet had any substantive comments from them. But, having looked at 
>the schema, it does seem that you have decided not to make the changes I 
>suggested in our last conversation.

Yes, because my responses to your suggested changes have gone unanswered, by
you or anyone else, since I posted them two weeks ago.  As I've mentioned,
my company is looking to transition to Bugzilla in the very near future, and
I can't afford to dawdle.

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

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

>The problem 
>it's designed to be solved can be solved much more simply by a per-field 
>multiselect of products, and a per-product multiselect of fields (on 
>different pages, naturally), so admins can attack the mapping problem 
>from both sides. (There would also be a per-group checkbox "add this 
>field to new products", and a per-product checkbox, "add this product to 
>new custom fields".)

This is a minimalist approach to field sharing, which seems to me as if
it would be awkward and confusing.  (I expounded on this in my previous
message.)  It sure would be swell if other developers would weigh in--
*cough* *cough*--since right now it seems like one person's opinion
versus one other person's opinion, which isn't terribly statistically
signiificant.

In any case, field-product membership should be determinable by a single
SELECT statement whichever way we ultimately go, so I'll keep plugging away
with my scheme for the time being.

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


-- 
Sean McAfee -- etzwane at schwag.org