Please make it optional for the user to view quips (as shown in the bug list page).

I see no reason why being able to turn on/off the quips needs to be an individual user preference. There's a global preference for the site. I think humoring this enhancement request would be a waste of time. The quips are just there for fun, and eye candy -- let the site maintainer decide whether they will use them. Just my 2 cents :)

Matthew, do you expect me to ask the Mozilla.org admin to turn them off for bugzilla.mozilla.org? Maybe I don't consider them eye candy but annoying? Please take a look at the bugzilla.mozilla.org quip file and see how much it is abused.

moving to real milestones...

-> Bugzilla product, General component (for now), reassigning.

We should add a class to the element the quip is in, then Ben can hide it with a user stylesheet. Gerv

I learnt to ignore the quips, and they are better maintained now (I think). But Gerv's suggestion would be a nice and simple solution for this bug.

FWIW, bugzilla.mozilla.org now has them completely disabled because of the amount of abuse they got.

I'm not working on this personally in the near future

Hi, this bug isn't of much importance, right. But i think it would be nice to have the possibility to turn it of and on by groups for having this "eye candy" for your developers and leaving the bugzilla pages "serious" for custommers. any chance for that in some "near" future ??

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

I need something to implement along with bug 98123 both for display purposes, and to ensure that it works. This one is nice and simple, and fits the bill. Taking it, and I'll land it at the same time (or shortly after) I land 98123.

Here we go... first actual implementation of the new User Settings. You will have to apply the latest patch at bug 98123 before applying this, or it's not going to work; both of them have to land together, see, so that one's waiting for this one to be ready. One review, and out! (I hope. :)

Comment on attachment 176188 [details] [diff] [review] Code patch for tip I turn display_quips off and I still see a quip at the top of the buglist. >+sub setting_exists ($) >+{ >+ my ($name) = @_; >+ my $sth = $dbh->prepare("SELECT name FROM setting WHERE name='$name'"); Use a placeholder there, instead of the manual quotes. >+ return 1 if ($sth->rows); >+ return 0; I'd write that "return $sth->rows ? 1 : 0;". >+ $dbh->do(qq{INSERT INTO setting (name, default_value, is_enabled) >+ VALUES ('$name', '$default_value', 1)}); Use placeholders, pwease. :-) >+ my $sth = $dbh->prepare(qq{INSERT INTO setting_value (name, value, sortindex) >+ VALUES ('$name', ?, ?)}); Nit: I'd prefer $dbh->quote or a placeholder rather than manual quotes. Some DB's don't use single-quotes, believe it or not. :-( (Not an issue yet, but it might be in the future.) >+# 2005-03-03 travis@sedsystems.ca -- Bug 41972 >+add_setting ("display_quips", {"on" => 1, "off" => 2 }, "on" ); I like that; very clean and keeps code out of checksetup, which I like. :-) >+ [% ELSIF error == "setting_addition" %] I think we could use a clearer error name... >+ If the parameter 'quip_list_entry_control' is set to <q>on</q>, Should be 'open', I think.

Most of your issues moved to 98123 when that code moved too. I think the only thing that's still left here that you had a problem with was the very last comment, and that's been fixed. Again, if you're going to test this, don't forget to apply the latest patch on bug 98123 first.

Comment on attachment 176901 [details] [diff] [review] Code patch for tip, take 2 (Apply with -P1) Yep, works and looks good to me. :-)

Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.366; previous revision: 1.365 done Checking in defparams.pl; /cvsroot/mozilla/webtools/bugzilla/defparams.pl,v <-- defparams.pl new revision: 1.154; previous revision: 1.153 done Checking in quips.cgi; /cvsroot/mozilla/webtools/bugzilla/quips.cgi,v <-- quips.cgi new revision: 1.27; previous revision: 1.26 done Checking in Bugzilla/Config.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v <-- Config.pm new revision: 1.36; previous revision: 1.35 done Checking in template/en/default/global/setting-descs.none.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/setting- descs.none.tmpl,v <-- setting-descs.none.tmpl new revision: 1.2; previous revision: 1.1 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user- error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.102; previous revision: 1.101 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.33; previous revision: 1.32 done Checking in template/en/default/list/quips.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/quips.html.tmpl,v <-- quips.html.tmpl new revision: 1.14; previous revision: 1.13 done

[from inspection of patch] ($param{'enablequips'} eq 'off') seems not to be handled on upgrade... Shouldn't that set the site default to off with the user setting disabled or something?

It's handled... but it's only handled in terms of the quips list, not quips display. I guess it doesn't bother me that much that people gain their own control of display... but your approach seems reasonable. Feel free to open a new bug and assign it to me if you feel strogly about it.

(In reply to comment #18) > It's handled... but it's only handled in terms of the quips list Ok if you say so. I could only see reference to translating the 'on', 'approved', and 'frozen' to 'open', 'moderated', and 'closed' respectively with apparently no handling of the old 'off' value. > Feel free to open a new bug and assign it to me if you feel strogly about it. At least for now I'll leave that to someone that's actually run the script and/or seen the administrative UI for this. I've not had an opportunity to upgrade yet myself (still on 2.16.X where the param is called 'usequip' and is just 'on' or 'off').

(In reply to comment #19) > (In reply to comment #18) > > It's handled... but it's only handled in terms of the quips list > Ok if you say so. Nope, even though I say so, I'm not always right. :) Bug 285689 was opened by someone else to deal with this issue, and they finally got through to me what they were saying (which was the same thing you are saying); a fix was just checked in to the trunk today.

Added to the release notes in bug 286274.

there's no 'General Preferences' docs so this includes another params on the page. This does s/Settings/Preferences/g; to coordinate with the code.

Comment on attachment 212093 [details] [diff] [review] docs patch for tip v1 + You can select the bug youe changed this time, or the next I assume "youe" should be "you've"; I'll change it upon checkin.

Checking in webtools/bugzilla/docs/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml new revision: 1.38; previous revision: 1.37 done Checking in webtools/bugzilla/docs/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml new revision: 1.37.2.1; previous revision: 1.37 done Checking in webtools/bugzilla/docs/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml new revision: 1.33.2.4; previous revision: 1.33.2.3 done

The checked in patch (the one with the "youe" --> "you've" change)