100137 - param to disable adding new quips

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[James Paige]

The ability to add new quips to mozilla.org's bugzilla has been desabled for
quite some time. According to Dawn Endico in bug 100104

> This is on purpose. The a large percentage of quips added were
> inappropriate and had to be deleted. Maintaining the quips list
> is simply more trouble than its worth.

If bug 100104 is WONTFIX then clicking on a quip should not lead to a page that
prompts users to add their own quips.

have a look at
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/buglist.cgi#1343

That line currently reads:

  print "<HR><A HREF=quips.cgi><I>$quip</I></A></CENTER>\n";

In mozilla.org's installation, it should be changed to:

  print "<HR><I>$quip</I></CENTER>\n";

Comment 1

[James Paige]

oops. fixing summary.

Comment 2

[Dawn Endico]

Note that we have quips turned on and i have no intention of turning them off.
We display quips, we just don't allow the addition of new ones. Disabling the
addition of new quips is not a feature of bugzilla. I did that by changing
file permissions. Making the change you suggests means forking the code which
I am not going to do (that is, using a version that differs from the bugzilla
trunk).

If anything, bugzilla should have a new parameter that allows people to turn
off the addition of quips. However I consider that a big waste of time. There
are so many important things to do. Quips are supposed to be fun. So what if
it doesn't work right. Marking this bug WHOCARES.

Comment 3

[James Paige]

*laugh*
I can see that quips is a touchy subject :)

> ... However I consider that a big waste of time. There
> are so many important things to do ...

Thats why I filed it at "trivial" severity

Comment 4

[Dave Miller [:justdave]]

Moving this to Bugzilla so someone might actually do something about it....
Someday.......

Comment 5

[Matthew Tuck [:CodeMachine]]

I think it's best to be able to specify a group that can add quips, once we've
done the groups rewrite.

Comment 6

[Bradley Baetz (:bbaetz)]

Since quips are now in the db, bmo's trick of making the quips file non-writable
won't work anymore

Assuming that bmo still wants this disabled (we don't allow html quips anymore,
so I don't know if it does), this would then presumably be a bmo blocker, so its
needed for 2.18.

(Note that the pre-db code doesn't give an error when quip addition fails)

Comment 7

[Joel Peshkin]

Attachment: Add param to restrict entry of quips

New parameter quippergroup added to restrict what group may add quips.	This
could be restricted to a group like editbugs immediately.   For sites that want
to disable quip entry altogether, a non-existant group can be specified.

Comment 8

[Luis Villa]

Comment on attachment 95355 [details] [diff] [review]
Add param to restrict entry of quips

Works here on bugzilla-test.gnome.org and the code itself looks fine. Giving
first-review. I'd probably suggest a more explanatory error message, probably-
maybe 'You do not have the necessary permissions to add quips' or something
like that. [Still completely unclear on the review granting mechanism- should I
be 'grant'ing when I've given first review or is that supposed to wait until
second review?

Comment 9

[Matthew Tuck [:CodeMachine]]

I think this should wait until the new group system gets in.  After this time,
the ID can be stored in the param.  This will then respect group renaming
properly.  If we do this earlier, we will need to include upgrade code.

Comment 10

[Gervase Markham [:gerv]]

This is not the correct approach to disabling quip addition. We are trying to
reduce the number of Params, in favour of Doing The Right Thing or other
configuration mechanisms. Having more than one param for a minor feature such as
quips is overkill.

If a site wants to use quips (usequips on) but feels it can't trust those with
editbugs to add quips, that's a pretty rare situation. "rm quips.cgi" and a
quick edit of the relevant templates to remove the links seems perfectly reasonable.

I personally think that, now the userid of the quip submitter is stored, b.m.o.
should allow users to contribute quips again when it upgrades to get quips-in-db.

Gerv

Comment 11

[Matthew Tuck [:CodeMachine]]

This is the correct approach to disabling quip addition.  The solution to too
many params is to separate some into different param tabs that are logically
ordered, and to move others to where they belong (eg product groups to the
product page).  I understand the need to reduce prefs, but there is no other way
to do this that would work reasonably.

As has been stated before, editbugs is not a long term solution as it will be
going away with fine-grained security.  Also, all of the system groups will be
becoming params anyway as a part of bug #147276, and this will fit in nicely
with that.

Comment 12

[Bradley Baetz (:bbaetz)]

Bug 147276 isn't happening the newar future, although I do think that splitting
up permissions from groups is a good idea.

However, I don't think that a param for the group to use is a good idea. Get the
groups rewrite in (so that we can add more groups without running into the
limit), and then add another group.

OTOH, gerv's right - if bmo wants to reenable this, we can move this bug back to
future, and have bmo add a warning about inappropriate quips to the addquip page.

Comment 13

[Joel Peshkin]

Attachment: Revised patch keeps total number of params constant

usequip (formerly on/off) has been replaced by enablequips (on/frozen/off) with
the  default being set to match the old usequip.  Hopefully, this also makes a
good example of how to propagate defaults.

Comment 14

[Gervase Markham [:gerv]]

OK, this is an improvement - but we still haven't demonstrated customer need
(assuming I persuade Dawn and Myk to reenable quips on b.m.o. now that they can
be tracked down to a user, which I have every hope of doing.)

A _useful_ quip enhancement would be a "nuke quip" button which appeared next to
the quip for people with high privilege levels, so they could quickly kill a
quip they got given which they thought was offensive.

Gerv

Comment 15

[Bradley Baetz (:bbaetz)]

dawn was rather adamant about keeping them disabled, to avoid her havin gto
police quips, and argue about who can add them, and edit them manually via the
db interface, and so on.

Comment 16

[Gervase Markham [:gerv]]

> dawn was rather adamant about keeping them disabled, to avoid her havin gto
> police quips, and argue about who can add them, and edit them manually via the
> db interface, and so on.

If people knew that they were accountable, there would be no policing necessary,
because people wouldn't be dumb enough to add offensive ones. If we added the
"nuke quip" button, there would be no need to edit them via the DB, either.

Gerv

Comment 17

[Joel Peshkin]

I'm going to let this bitrot until a consensus emerges on the right thing to do
with this.  (I'm easy)

Comment 18

[James Cox]

Comment on attachment 95408 [details] [diff] [review]
Revised patch keeps total number of params constant

this is fine imho. Works as it says on the tin. :)

Comment 19

[J. Paul Reed [:preed]]

Comment on attachment 95408 [details] [diff] [review]
Revised patch keeps total number of params constant

Looks good to me; and you mean that multi-select code works?!

That's odd... ;-)

r=preed

Comment 20

[Joel Peshkin]

Checking in defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: 1.84; previous revision: 1.83
done
Checking in quips.cgi;
/cvsroot/mozilla/webtools/bugzilla/quips.cgi,v  <--  quips.cgi
new revision: 1.11; previous revision: 1.10
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <-
-  list.html.tmpl
new revision: 1.8; previous revision: 1.7
done

Comment 21

[Pascal Chevrel:pascalc]

Attachment: Link to Github pull-request: https://github.com/mozilla/bedrock/pull/1919

I did a PR to fix that, cool to have Japanese now on mozilla.org :)

Comment 22

[Frédéric Buclin]

Comment on attachment 8412555 [details] [review]
Link to Github pull-request: https://github.com/mozilla/bedrock/pull/1919

Wrong bug. You meant bug 1001377, not this one.