156174 - use* param checks are not consistent

Status: RESOLVED INCOMPLETE

(Bugzilla :: Bugzilla-General, defect)

Description

[Bradley Baetz (:bbaetz)]

Bugzilla has several parms for enabling and disabling features. The current list is:

- quip
- buggroups
- buggroupsentry
- LDAP
- targetmilestone
- qacontact
- statuswhiteboard
- browserinfo
- dependencies

I also have a patch which adds 'usevotes' to the list.

Some of these (buggroup, quip, browserinfo) are checked. Others
(target_milestone, qa) are usually checked for the ui, but not in the backend.
Some (dependencies) are only checked in one place (Bug.pm's xml output sub),
making the param useless.

query.cgi's advanced stuff doesn't check any of the params, but thats probably
ok, for historical queries, for example.

We need to decide which of these params should be kept (Does anyone really want
to disable dependencies?), and enforce those which are going to remain optional
in both the frontend and the backend.

Comment 1

[Gervase Markham [:gerv]]

I was thinking this recently as well. How to enable/disable votes is a serious
FAQ, and this param will certainly help. But you are also right about the wider
issue - we need to decide which bits of the UI are switchable on and off via
params, and which mean people should edit the templates so the field still
exists but is never used.

Gerv

Comment 2

[Jouni Heikniemi]

Yes, this is important. 

I also think there are situations where you might want to disable dependencies.
I've been considering that, actually (on a special case installation). If
Bugzilla is used to contain something trivial like helpdesk trouble tickets,
their simple dependencies (if any) can be handled by duping -> removing deps
makes the UI easier to use. 

But I agree that we should go through the parameters one by one and reconsider.
The above would be trivial to do with a simple template modification, too...

Comment 3

[Gervase Markham [:gerv]]

When custom fields arrive ( ;-) ) then thinks like URL and Status Whiteboard
will just become default custom fields. But, in the mean time, here's a straw
man proposal:

Keep:

- quip
- buggroups
- buggroupsentry
- targetmilestone
- qacontact
- statuswhiteboard
- LDAP (although we need to make the auth mechanism more modular; it's currently
a mess)

Add:

- usevotes
- useunconfirmed (turning this on via votes is non-obvious)

The above two items are among our most frequent FAQs.

Kill:

- browserinfo - this stuff should be in custom templates
- dependencies (disabling should be in the UI - it's just cutting a section from
edit.html.tmpl)

Gerv

Comment 4

[Bradley Baetz (:bbaetz)]

Except that while usevotes has global implications (for the footer), use
unconfirmed is much more a product thing.

Comment 5

[Gervase Markham [:gerv]]

Yes; but, following the principle of usevotes, useunconfirmed's mechanism is
much more discoverable if there's a param which says "Turn this on to use
UNCONFIRMED. You must then enable it per-product by setting votestoconfirm to > 0."

I also think "confirmed by popular vote" is a silly feature. There are enough
people with canconfirm around now that it shouldn't be an issue; and it
complicates matters.

Gerv

Comment 6

[Bradley Baetz (:bbaetz)]

True. 111 of bmo's bugs have the string "confimred by popular vote" in them
(including this one...), gving about 0.7% of bugs which have been confirmed this
way.

When you remove the 45 INVALID/DUPL/WONTFIX ones, that leaves 0.04% - ie not
enough to be worth it.

Comment 7

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 8

[Frédéric Buclin]

Click the URL field to see bugs we filed for each parameter which should go away, based on one of our Bugzilla meetings:

https://wiki.mozilla.org/Bugzilla:Params

Other parameters will be left untouched, at least for now. In any case, we should have one bug per parameter, not a meta-like bug.