Closed Bug 148564 Opened 23 years ago Closed 12 years ago

Ability to ignore specific bugs (not get email from them, even as the reporter)

Categories

(Bugzilla :: Email Notifications, enhancement, P3)

Product:
Bugzilla
Component:
Email Notifications
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 5.0

People

(Reporter: netdragon, Assigned: dkl)

References

Details

Attachments

(2 files, 7 obsolete files)

Patch to block all email from a bug for a particular user (v8)
17.24 KB, patch
LpSolit
: review+
Details | Diff | Splinter Review
mail from a Bugzilla version 4.4.1
9.95 KB, application/mbox
Details
There should be the ability to list users and bugs to ignore emails from in prefs. If you are CCed on a bug, it will still ignore the bug. That way, you can ignore a bug but still stay CCed on it for your buglist. Bug owners, module owners, and QAs will still recieve emails for a bug they belong to.
See also bug 117928: "ability to not get mail when certain users comment".
Renaming this to "specific bugs" since there really should be only one issue for bug reports and it seems like "users" is already covered
Summary: Ability to ignore specific bugs and users in prefs → Ability to ignore specific bugs in prefs
This feels plain wrong because I don't see why it would make sense to stay on a CC list when you don't want the mail anyway. I don't think this should be implemented, although I do understand why it was proposed. However, a much better solution IMO is to have personal keywords and use them to construct your buglist.
Priority: -- → P5
consider this alternative reason for implementing this: you are getting bugmail for a bug because you are watching somebody, but you do not want to get mail for this specific bug. however, you generally do want to watch that person. would that be a good justification for this feature?
What it sounds like is that we need a way to bookmark bugs, but not get mail from them. I set up another bugzilla account for myself that I add to the CC list. It doesn't get mail, but I can search for bugs where it is CCd. Personally, I prefer the white-list approach to getting bugmail.
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → user-accounts
(In reply to comment #3) > This feels plain wrong because I don't see why it would make sense to stay on a > CC list when you don't want the mail anyway. Maybe the CC list is not a good example, but comment 4 is. Also, maybe you are the reporter of a bug, but don't want to get bugmail from the bug. And as you cannot remove your role from the bug, the only way to not be annoyed with bugmail is to blacklist the bug.
Pushing this bug into my radar.
Assignee: user-accounts → LpSolit
Component: User Accounts → Email Notifications
Target Milestone: --- → Bugzilla 3.2
Attached patch patch, v1 (obsolete) — — Splinter Review
The UI is very simple for now. But we can improve it in a separate bug if we want something similar to the watch list.
Attachment #284623 - Flags: review?(mkanat)
Comment on attachment 284623 [details] [diff] [review] patch, v1 >@@ -358,6 +364,30 @@ sub SaveEmail { >+ my %seen; >+ $seen{$_} = 1 foreach @$old_buglist; Nit: That could be my %seen = map { $_ => 1 } @$old_buglist. >+ my $new_buglist = $cgi->param('bugs_blacklist') || ''; >+ my @new_buglist = grep { detaint_natural($_) } split(/[\s,]+/, $new_buglist); >+ my ($removed, $added) = diff_arrays($old_buglist, \@new_buglist); >+ >+ if (scalar @$removed) { >+ $dbh->do('DELETE FROM bugs_blacklist WHERE user_id = ? AND bug_id IN (' . >+ join(', ', @$removed) . ')', undef, $user->id); >+ } >+ if (scalar @$added) { >+ my @added = grep { !$seen{$_}++ && $user->can_see_bug($_) } @$added; That may be very nice and compact, but it's almost impossible to read. Can we make that two separate lines of code instead? >Index: Bugzilla/User.pm >+sub bug_blacklisted { Let's make it bug_ignored instead. "blacklisted" could mean too many things. >+ my $is_blacklisted = $dbh->selectrow_array('SELECT 1 FROM bugs_blacklist >+ WHERE user_id = ? AND bug_id = ?', >+ undef, $self->id, $bug_id); You could also select the user's whole blacklist and grep it. Then you could cache the blacklist. I'm not certain it matters, though. >Index: Bugzilla/DB/Schema.pm >+ bugs_blacklist => { Call it email_bug_ignore instead, so that it's more grouped with the email preferences. Oh, and thank you for adding REFERENCES! That makes me very happy. :-) >+ bugs_blacklist_idx => {FIELDS => [qw(user_id bug_id)], TYPE => 'UNIQUE'}, bugs_blacklist_user_id_idx Names are *always* "table, column, _idx". I think I should just make DB::Schema enforce that, and we can have an override_name parameter for when it's not that. (I filed bug 399686 for that.) >Index: template/en/default/account/prefs/email.html.tmpl >+<b>[% terms.Bugs %] Blacklist</b> "Ignore Bugs" >+ You can blacklist [% terms.bugs %] from which you don't want to get [snip] I like this, but it can be much shorter: You can put a bug ID in this comma-separated list if you never, ever want to get any notifications about that bug for any reason.
Attachment #284623 - Flags: review?(mkanat) → review-
(In reply to comment #11) > >+ my @added = grep { !$seen{$_}++ && $user->can_see_bug($_) } @$added; > > That may be very nice and compact, but it's almost impossible to read. Can we > make that two separate lines of code instead? It's a very common way to avoid duplicated entries in an array. I think it's time for people to start understanding how this kind of logic works instead of writing several lines of code again and again. All I will do is to add a comment explaining that I'm filtering duplicated entries. http://www.mamiyami.com/document/oreilly/perl3/cookbook/ch04_07.htm#ch04-17367 I already started using this way to filter stuff and am going to use it more and more.
Status: NEW → ASSIGNED
Attached patch patch, v2 (obsolete) — — Splinter Review
$user->bug_ignore now cache and returns the whole list of ignored bugs if no bug ID is passed as argument, which makes the code much simpler in userprefs.cgi as no additional SQL query is required to get the whole list. I also updated the documentation to mention this new feature (and fixed some obsolete comments about the email prefs tab). About my previous comment, I asked myk on IRC, and he agrees with me that my code is easily readable, so I didn't change it (but only added a comment describing what the grep {} does).
Attachment #284623 - Attachment is obsolete: true
Attachment #285217 - Flags: review?(mkanat)
(In reply to comment #12) > I think it's time for people to start understanding how this kind of logic > works What you're asking is for *random people* who we've *never met* and *never will meet* to *become better Perl programmers* just so they can *understand our code*. The correct solution in this case is to create a simple function. We could definitely use a "uniq" or "uniq_array" function in Bugzilla::Util anyhow, we've needed it enough. A function name is always easy to read, if you make it a good function name. One reason functions exist is to hide complexity in exactly these sorts of circumstances.
(In reply to comment #14) > The correct solution in this case is to create a simple function. We could > definitely use a "uniq" or "uniq_array" function in Bugzilla::Util anyhow, > we've needed it enough. First of all, Bugzilla is not a Perl tutorial. Secondly, this code is simple enough to be understandable. If programmers do not understand it, then they have other troubles when hacking our code. And my usage of can_see_bug() makes it not suitable for Bugzilla::Util.
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Priority: P5 → P3
Max, could I get some traction on this review?
Please explain how bug 215588 is a duplicate of bug 148564. Bug 215588 would allow the E-mail on bug changes to be disabled for the reporter. Doesn't bug 148564 apply only to addressees in the CC list? Is so, the reporter (who us not usually found in the CC list) would still receive such E-mail. Six years ago, I wrote bug 210251 to report a problem with Talkback. Since Talkback has been eliminated from Mozilla products (or is at least being phased out), this bug has been overcome by events. The bug was marked Resolved WontFix almost two years ago. I'm no longer interested in this bug. No one should be interested in this bug. However, someone updated bug 210251 just three weeks ago, changing the Product from Core to Core Graveyard. I got another automatic E-mail about that update. I don't want to see any more such messages.
(In reply to comment #20) > Doesn't bug 148564 apply only to addressees in the CC list? No, my patch applies to reporters too. In fact, it blocks everything coming from the bugs you no longer care about, independently of your roles with these bugs.
Comment on attachment 285217 [details] [diff] [review] patch, v2 Okay, instead of this, what I'd like to see is a checkbox on show_bug.cgi, perhaps under "Reporter", that says something like "Ignore this bug".
Attachment #285217 - Flags: review?(mkanat) → review-
Summary: Ability to ignore specific bugs in prefs → Ability to ignore specific bugs (not get email from them, even as the reporter)
Assignee: LpSolit → email-notifications
Status: ASSIGNED → NEW
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
BMO has requested such a feature so I will take the patch forward and submit a new one for review. Thanks dkl
Assignee: email-notifications → dkl
Status: NEW → ASSIGNED
Attachment #285217 - Attachment is obsolete: true
Attachment #701216 - Flags: review?(LpSolit)
Target Milestone: --- → Bugzilla 5.0
Comment on attachment 701216 [details] [diff] [review] Patch to block all email from a bug for a particular user (v3) We would like this to be included in BMO before 5.0 so I will also request glob to review as well, whoever can get to it first. dkl
Attachment #701216 - Flags: review?(glob)
Comment on attachment 701216 [details] [diff] [review] Patch to block all email from a bug for a particular user (v3) Review of attachment 701216 [details] [diff] [review]: ----------------------------------------------------------------- this patch contains trailing whitespace, please remove. ::: Bugzilla/BugMail.pm @@ +264,5 @@ > + # is ignored, there is no need to do additional checks. > + if ($user->email_disabled || $user->bug_ignored($id)) { > + push(@excluded, $user->login); > + next; > + } $user->email_disabled duplicates the $user->email_enabled check a little later: > # Make sure the user isn't in the nomail list, and the dep check passed. > if ($user->email_enabled && $dep_ok) { i think the new location is better, so please remove the ->email_enabled check ::: template/en/default/account/prefs/email.html.tmpl @@ +297,5 @@ > +[% IF user.bug_ignored.size %] > + <p> > + Your current list of ignored [% terms.bugs %] is:<br> > + [% user.bug_ignored.join(', ') FILTER html %]. > + </p> rather than a single text field with a comma seperated list of bug ids on the email prefs tab, i think it would be cleaner to display each bug with the id, summary and a checkbox (similar to how voting displays your votes). the current ui would work for a handful of bugs, but would quickly be hard to manage should you need to edit a list containing more bugs than that. @@ +301,5 @@ > + </p> > +[% END %] > + > +<input type="text" id="email_buglist_ignored" name="email_buglist_ignored" > + size="60" value="[% user.bug_ignored.join(', ') FILTER html %]"> having a text field to add bugs to the list makes sense, so please morph this field to "add bugs" instead of "edit the list". ::: userprefs.cgi @@ +356,5 @@ > + join(', ', @$removed) . ')', undef, $user->id); > + } > + if (scalar @$added) { > + # Filter duplicated entries and bugs the user cannot see. > + my @added = grep { !$seen{$_}++ && $user->can_see_bug($_) } @$added; i don't think we need to remove bugs which the user cannot see from this list. as it is currently, if someone adds a bug when it's public, then the bug is protected, editing anything on the email prefs field will silently remove that bug from the list. should the bug then be made public again, the user will start receiving bugmail which they have already opted out of. @@ +360,5 @@ > + my @added = grep { !$seen{$_}++ && $user->can_see_bug($_) } @$added; > + my $sth = $dbh->prepare('INSERT INTO email_bug_ignore > + (user_id, bug_id) VALUES (?, ?)'); > + $sth->execute($user->id, $_) foreach @added; > + } currently invalid bug ids are silently ignored. i entered a bug /alias/ instead of a id, and wasn't informed this was invalid. if someone wasn't paying attention, they could hit save and move on, even though the action failed. with this field changing to "add these bugs" instead of an "edit the bug list", we could validate each id when it's added, and also support mapping aliases to bug ids.
Attachment #701216 - Flags: review?(glob) → review-
The new patch will block an ID the user cannot see but will not clear an ID that the user is blocking that is made private after. Also aliases work properly now. dkl
Attachment #701216 - Attachment is obsolete: true
Attachment #701216 - Flags: review?(LpSolit)
Attachment #724631 - Flags: review?(glob)
Comment on attachment 724631 [details] [diff] [review] Patch to block all email from a bug for a particular user (v4) Review of attachment 724631 [details] [diff] [review]: ----------------------------------------------------------------- looks like this patch was made against bmo/4.2, not bugzilla/trunk, so it doesn't apply cleanly. this patch contains trailing whitespace, please remove. from just reading the code i don't see anything amiss, but i'll need an updated patch to test.
Attachment #724631 - Flags: review?(glob) → review-
Patch against trunk
Attachment #725151 - Flags: review?(glob)
Attachment #724631 - Attachment is obsolete: true
Comment on attachment 725151 [details] [diff] [review] Patch to block all email from a bug for a particular user (v5) Review of attachment 725151 [details] [diff] [review]: ----------------------------------------------------------------- great! r=glob ::: template/en/default/account/prefs/email.html.tmpl @@ +298,5 @@ > + <tr> > + <td> > + <input type="checkbox" name="remove_ignored_bug_[% bug_id FILTER html %]" value=""> > + </td> > + <td>[% bug_id FILTER bug_link(bug_id) FILTER none %]</td> it would be nice to show the bug's summary here too (assuming the user has access to the bug), however it isn't worth blocking this feature for that. @@ +306,5 @@ > + </p> > +[% END %] > + > +<p>Add [% terms.bugs %]:<br> > + <input type="text" id="add_ignored_bugs" please remove trailing whitespace
Attachment #725151 - Flags: review?(glob) → review+
Flags: approval?
Comment on attachment 725151 [details] [diff] [review] Patch to block all email from a bug for a particular user (v5) >=== modified file 'Bugzilla/Bug.pm' >+ # Ignore all email for this bug if user has >+ # checked the ignore bug email checkbox >+ $self->{_bug_ignored} = $params->{'bug_ignored'} ? 1 : 0; When editing several bugs at once, 'bug_ignored' is not available in the UI and so this attribute is cleared. All bugs you were ignoring are re-enabled again. I suspect you have the same problem when calling Bug.update from our API. This is not the right place to set _bug_ignored. It should be done in process_bug.cgi itself, where other defined_foo checks are done, and update() should only care about this attribute if it's defined. >=== modified file 'Bugzilla/BugMail.pm' > # Make sure the user isn't in the nomail list, and the dep check passed. >- if ($user->email_enabled && $dep_ok) { >+ if ($dep_ok) { Please fix the comment. The "nomail list" check is now done earlier. >=== modified file 'Bugzilla/User.pm' >+sub bug_ignored { Please write two separate methods: is_bug_ignored($bug_id) or ignores_bug($bug_id) which always takes a bug ID and which returns true/false, and bugs_ignored() (plural) which returns an arrayref with currently ignored bugs. It's IMO confusing to have a method which can return either true/false or an arrayref. >=== modified file 'docs/en/xml/using.xml' >+ The <quote>Ignore Bugs</quote> section lets you specify a >+ comma-separated list of bugs from which you never want to get any >+ email notification of any kind. Flagmails coming from these bugs will still go through. So this text is inaccurate. >+ Invalid bug numbers and bugs you cannot see are silently skipped. This is not true. You call ->check() in userprefs.cgi and so it throws an error. >=== modified file 'template/en/default/account/prefs/email.html.tmpl' >+ <td> >+ <input type="checkbox" name="remove_ignored_bug_[% bug_id FILTER html %]" value=""> >+ </td> >+ <td>[% bug_id FILTER bug_link(bug_id) FILTER none %]</td> It's a pain to know which bugs we are talking about without the bug summary being displayed. And as the goal is to ignore too noisy bugs, I would say that displaying the Last Changed Date too would be helpful. It's an easy way for you to know if you missed something for these bugs. >=== modified file 'userprefs.cgi' >+ delete $ignored_bugs{$bug_id} if exists $ignored_bugs{$bug_id}; No need to check if the key exists. This doesn't hurt. >+ $dbh->do('DELETE FROM email_bug_ignore WHERE user_id = ? AND bug_id IN (' . You should ideally use $dbh->sql_in() so that Oracle doesn't complain when the list is too large. >+ if (scalar @$added) { >+ # Filter duplicated entries and bugs the user cannot see. This comment doesn't make sense here. Such entries are already filtered. It must go away.
Attachment #725151 - Flags: review-
Flags: approval?
Keywords: relnote
Attachment #725151 - Attachment is obsolete: true
Attachment #727195 - Flags: review?(LpSolit)
Attachment #727195 - Flags: review?(glob)
Comment on attachment 727195 [details] [diff] [review] Patch to block all email from a bug for a particular user (v6) Review of attachment 727195 [details] [diff] [review]: ----------------------------------------------------------------- please remove trailing whitespace. ::: template/en/default/account/prefs/email.html.tmpl @@ +308,5 @@ > + <td><a href="[% urlbase FILTER none %]show_bug.cgi?id=[% bug.id FILTER uri %]"> > + [% bug.id FILTER html %]</a> > + </td> > + <td>[% bug.status FILTER html %]</td> > + <td> - [% bug.summary FILTER html %]</td> we shouldn't be showing the summary to users who no longer have access to that bug.
Attachment #727195 - Flags: review?(glob) → review-
Attachment #727195 - Attachment is obsolete: true
Attachment #727195 - Flags: review?(LpSolit)
Attachment #727903 - Flags: review?(glob)
Attachment #727903 - Flags: review?(LpSolit)
Comment on attachment 727903 [details] [diff] [review] Patch to block all email from a bug for a particular user (v7) r=glob i'll hold off requesting approval pending lpsolit's review.
Attachment #727903 - Flags: review?(glob) → review+
Comment on attachment 727903 [details] [diff] [review] Patch to block all email from a bug for a particular user (v7) >=== modified file 'Bugzilla/Bug.pm' >+ my $user = Bugzilla->user; Nit: there are several places within update() which call Bugzilla->user. It would be better to define $user at the top of update() and then call $user->id everywhere instead of Bugzilla->user->id. But you can ignore this comment if you want. >+ if ($self->{'bug_ignored'} && !$user->is_bug_ignored($self->id)){ Add a whitespace between () and { at the end of the line. >+sub set_bug_ignored { $_[0]->set('bug_ignored', $_[1]); } These methods are listed alphabetically, so set_bug_ignored() must appear right before set_cclist_accessible(). >=== modified file 'Bugzilla/BugMail.pm' >+ # Email the user if the dep check passed. >+ if ($dep_ok) { > # OK, OK, if we must. Email the user. Nit: The "OK, OK, ..." comment can go away as you already say the same the line before. >=== modified file 'Bugzilla/User.pm' >+ FROM bugs, email_bug_ignore >+ WHERE bugs.bug_id = email_bug_ignore.bug_id Do not use a comma join + WHERE condition. Use INNER JOIN ... ON ... instead, to follow our guidelines. >+=item C<bug_ignored> >+ >+If a bug ID is passed, returns true if the user does not want email >+notifications for this bug, else returns false. If no bug ID is passed, >+returns an arrayref with all bugs being ignored. This method no longer exists. >+=item bugs_ignored >+ >+=item is_bug_ignored The goal of t/011pod.t to complain if new methods have no POD is to force developers to write POD, not to let developers add dummy POD. Please write real POD for these two methods. >=== modified file 'docs/en/xml/using.xml' >+ a noisy bug. Note that you can only blacklist bugs you can see. An >+ error will be displayed if you enter an invalid bug number or a bug >+ you cannot see. I wonder if this warning is really useful. >=== modified file 'template/en/default/account/prefs/email.html.tmpl' >+ <input type="checkbox" name="remove_ignored_bug_[% bug.id FILTER html %]" value=""> Write value="1". It must be set for checkboxes, per the HTML4 spec. >+ <td><a href="[% urlbase FILTER none %]show_bug.cgi?id=[% bug.id FILTER uri %]"> urlbase must be HTML filtered. >+ [% IF user.can_see_bug(bug.id) %] can_see_bug() is going to kill performance if you don't preload these bugs using $user->visible_bugs(). >=== modified file 'template/en/default/bug/edit.html.tmpl' >+ <label for="bug_ignored" title="Ignore all email for this [% terms.bug %]"> Shouldn't "email" be plural? >+ <input type="checkbox" name="bug_ignored" id="bug_ignored" value="1" >+ [% 'checked="checked"' IF user.is_bug_ignored(bug.id) %]> You must write ' checked="checked"', (note the whitespace before checked=), else it is concatenated with value="1" from the previous line, see the generated source of the HTML page. >=== modified file 'userprefs.cgi' >+ my $params = Bugzilla->input_params; I don't see the point to use Bugzilla->input_params as we already use Bugzilla->cgi in all CGI scripts. This is totally inconsistent with all other CGI scripts, as none of them use Bugzilla->input_params, which was designed for WebServices and extensions. For consistency and to not confuse other contributors, please use our standard way to get CGI values, i.e. $cgi->param('foo'). Otherwise looks good and works fine.
Attachment #727903 - Flags: review?(LpSolit) → review-
Attachment #727903 - Attachment is obsolete: true
Attachment #734752 - Flags: review?(LpSolit)
Comment on attachment 734752 [details] [diff] [review] Patch to block all email from a bug for a particular user (v8) === modified file 'Bugzilla/User.pm' >+=item C<is_bug_ignored> >+ >+If a bug ID is passed in, Why "If"? You must pass a bug ID. >=== modified file 'userprefs.cgi' >+ foreach my $key (grep(/^remove_ignored_bug_/, keys %{ $cgi->Vars })) { Simply write |$cgi->param()| instead of |keys %{ $cgi->Vars }|. Otherwise looks good. r=LpSolit with these two comments fixed on checkin.
Attachment #734752 - Flags: review?(LpSolit) → review+
Flags: approval+
Thanks! Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bugzilla/trunk modified Bugzilla.pm modified process_bug.cgi modified userprefs.cgi modified Bugzilla/Bug.pm modified Bugzilla/BugMail.pm modified Bugzilla/Flag.pm modified Bugzilla/Mailer.pm modified Bugzilla/User.pm modified Bugzilla/DB/Schema.pm modified docs/en/xml/using.xml modified template/en/default/account/prefs/email.html.tmpl modified template/en/default/bug/edit.html.tmpl Committed revision 8604.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Removed accidental code commits :( Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bugzilla/trunk modified Bugzilla/Mailer.pm modified Bugzilla.pm Committed revision 8605.
This is a very cool feature, but the name confused the heck out of me - I had to go to Glob's blog to figure out what it meant. Who, exactly, is ignoring the email? I don't think I can send email *to* Bugzilla, so it's probably not ignoring it, which is what the option title suggests. The second-best explanation is that it suppresses *sending* email somehow. But does it suppress it for everyone, or just for me? It turns out the latter is correct, but I only know that from http://globau.wordpress.com/2013/04/. How about putting "Never email me about this bug" next to the checkbox: Ignore Bug Mail: |_| Never email me about this bug
(In reply to Dustin J. Mitchell [:dustin] from comment #42) > How about putting "Never email me about this bug" next to the checkbox: > > Ignore Bug Mail: |_| Never email me about this bug Please file a separate bug for this.
Blocks: 861392
So happy this is RESOLVED FIXED. Now please advise on https://bugzilla.wikimedia.org/show_bug.cgi?id=48736 what to do.
(In reply to jidanni from comment #45) > So happy this is RESOLVED FIXED. > Now please advise on > https://bugzilla.wikimedia.org/show_bug.cgi?id=48736 > what to do. I would just advice the admin of that Bugzilla to upgrade to 4.4 (latest stable release) and then apply the patch from this particular bug to their Bugzilla code. This patch was only applied to trunk upstream which will likely be 5.0 and there has not yet been a timeframe set on when it will release. We (BMO) are using it without issue on 4.2.6 so you could possibly apply the back ported patch to that version as well like we did. Link to our checkin: http://bzr.mozilla.org/bmo/4.2/revision/8725 dkl
(In reply to David Lawrence [:dkl] from comment #46) > Link to our checkin: http://bzr.mozilla.org/bmo/4.2/revision/8725 You will also need: http://bzr.mozilla.org/bmo/4.2/revision/8731 dkl
Sounds 'simple'. OK I'll tell them.
Blocks: 877083
All I know is today I got a mail from a Bugzilla version 4.4.1 saying I was getting mail because I voted for the bug, but I still couldn't find a way to stop the mail without hurting my particular votes or influencing other things.
Oh I see. Expect a fix by 5.0. OK, sorry.
Added to relnotes for 5.0rc1.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: