178370 - global param for whether or not to send mail

Status: RESOLVED FIXED

(Bugzilla :: Email Notifications, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

There should be a global preference for whether or not to send mail, and no mail
should be sent by a Bugzilla script for any reason if the pref is turned off. 
This is particularly useful for test installations using real data where you
don't want real users getting fake emails when you make fake changes to the test
data.

Comment 1

[Dave Miller [:justdave]]

I'd like there to be some way from the admin interface to set the new user
defaults for this.

For example, on landfill, I'd have all new users default to no mail, and provide
instructions on the landfill front page for users to turn their mail pref on if
they want to see what the email looks like.

Comment 2

[Max Kanat-Alexander]

*** Bug 275633 has been marked as a duplicate of this bug. ***

Comment 3

[Max Kanat-Alexander]

This is trivial. We don't need to wait for SMTP in order to be able to implement
this param. We only need to wait until the major work being done to editparams
is complete.

Comment 4

[Shane H. W. Travis]

Max; why do we even need to wait for that? Yes, this adds another parameter, 
but it seems to me that it neither blocks nor is blocked by the work being done 
on bug 46296. They are simply working on the same section of code (which 
happens fairly frequently around here....)

Comment 5

[Max Kanat-Alexander]

OK. If the patches don't conflict, then go ahead! :-) Take the bug, by the way,
if you want to do it.

This should be fairly simple now that bug 59351 has checked-in.

Comment 6

[Dave Miller [:justdave]]

(In reply to comment #4)
> Max; why do we even need to wait for that?

In theory, the reason it was blocking is because the editparams page is
currently a UI nightmare, and every param we add just makes it worse.  However,
I'm perfectly willing to let params get added now (on the trunk only) at will,
since I'm reasonably sure the editparams rewrite will be done before 2.22, and
I'm happy to deal with param conflicts while working on that (i.e. I can just
move them into the new system before it lands)

Comment 7

[Shane H. W. Travis]

I keep needing this, so I'll take this bug.

Comment 8

[Shane H. W. Travis]

Attachment: Code patch for tip

Huge thanks to Max for making this one possible.

Comment 9

[Shane H. W. Travis]

Attachment: Code patch for tip, take 2

Bah, missed the obvious way to use this in BugMail.pm -- thanks Colin.

Comment 10

[Frédéric Buclin]

Comment on attachment 175833 [details] [diff] [review]
Code patch for tip, take 2

I like this patch. r=LpSolit

Comment 11

[Max Kanat-Alexander]

FWIW, this isn't quite as useful as setting the maildeliverymethod to "testfile."

Comment 12

[Shane H. W. Travis]

Checking in defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: 1.150; previous revision: 1.149
done
Checking in Bugzilla/BugMail.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v  <--  BugMail.pm
new revision: 1.35; previous revision: 1.34
done

Comment 13

[Jacob Steenhagen]

It seems to me that the extra param problem could have been easily avoided by
adding a "none" option to the maildeliverymethod param.

Comment 14

[Shane H. W. Travis]

Jake, I completely agree. I was unaware of this parameter when I made my patch, 
and Max's comment never twigged me to the idea that I could just add 'none' to 
the existing parameter.

I'm opening a new patch to address the issue and merge the two into one.

Comment 15

[Frédéric Buclin]

This parameter didn't live long enough to be in the documentation. It has been replaced by a new parameter, see bug 284629.