23924 - Editing/Mass-changing bugs should allow a "discreetly" option

Status: RESOLVED DUPLICATE of bug 1062718

(Bugzilla :: Bugzilla-General, enhancement, P2)

Description

[ekrock's old account (dead)]

Frequently, I'll make a minor change to a bug and feel bad about all the
confirmation emails that go out. Excessive emails are already causing some
engineers to abandon the tracking of email notifications completely, relying on
queries instead.

It would be nice if people editing a bug had the option (via a "Don't send
email" or "Don't spam the world" checkbox next to the Commit button) to suppress
the automatic confirmation email.

This requires some trust of the editor's judgement and good intentions, of
course, but I think it would be well received and used.

Comment 1

[Terry Weissman]

The potential for misuse scares me.

For example, see bug 20841.  Just yesterday, I finally fixed it.  This change
would undo the benefits; it makes it possible to silently remove a bug from
someone's radar.

There needs to be some kind of accountability here, or something.

Comment 2

[ekrock's old account (dead)]

I agree with you that there's risk on this. If we implemented the "personal
control panel" idea for bugzilla notifications (#23925) then there could be a
preference to override this silent change checkbox. (i.e. checkbox: "I don't
care if they don't want to send a mail confirmation, spam me anyway ...")

I'm also concerned however about the risk that we'll get such a blizzard of bug
notifications after beta that people will become unable/unwilling to use mail
notifications at all. We've gotten something like 5000 bugs filed the whole
project long on the browser component, right? (I could be off but it's
something like that.) We could get that many the first *week* of beta--tons of
well-intentioned DUPs and INVALIDs to wade through.  If mail notifications are
to be kept useful and usable, I think we'll have to find some ways to cut down
the number of them.

Comment 3

[Matthew T (active 1999-2002)]

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

Comment 4

[Matthew T (active 1999-2002)]

It would be far better, I think, to allow recipients control over which fields 
they want to be notified about changes to (a bunch of checkboxes in their user 
profile), than to allow senders to choose which notifications get sent. It's 
pretty obvious that recipients are more likely to know what is important to 
themselves than senders are.

This would get around the misuse/annoyance juggling act, because developers would 
be able to have notification of changes to AssignedTo turned on, and notification 
of changes to CC turned off (for example).

Comment 5

[Jim Race]

That indeed sounds like the way to go. Might I even suggest going so far as to 
include somehting in the mailto: subject line for that same concept that would 
allow developers to filter email. Perhaps one letter, that signifies a minor vs. 
significant change, for example...

Comment 6

[Matthew Tuck [:CodeMachine]]

Bug #14137 guys, bug #14137.

Comment 7

[Matthew T (active 1999-2002)]

Well if there aren't any objections, I'll mark this as wontfix, and y'all can git 
over to bug 14137 instead, since that bug makes this one obsolete.

Comment 8

[Matthew Tuck [:CodeMachine]]

Verif.  I too think this idea is bad, but an implementation of bug #23925 would
make me glad.

Comment 9

[Matthew Tuck [:CodeMachine]]

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

Comment 10

[Dave Miller [:justdave]]

moving to Bugzilla product
reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE

Comment 11

[Jason Bassford]

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

Comment 12

[Joel Peshkin]

When an edit or mass change is made to a bug, the firm should include a
"discreetly" checkbox indicating that the person doing the change does not feel
that bugmail is justified.

When the bug is processed, this should cause the bugmail to be supressed for any
users who have selected the option to supress bugmail for discreet changes.

This should probably be configurable based on the relationship of the user to
the bug.  It is likely that I do not want to be notified of trivial changes to a
bug on which I am a CC list member, but I do want to be notified of those same
trivial changes if I reported it or am assigned to it.

Comment 13

[Joel Peshkin]

If bug 172447 is a dupe of this, then this must do what bug 172447 requires

Comment 14

[timeless]

i'd much prefer batching mass changes over allowing someone to hide them.

i'm not sure there's a bug for batching but basically you'd get a single bugmail
that would list all of the changed bugs that you're allowed to know about with
information about their changes.  If you don't care about what was done then you
delete/ignore that one email.

Comment 15

[Harlan Stenn]

Would it help if there was a way to have bugzilla send out "digest" email?

For example, I made changes to a bunch of bugs (I forget if it was target 
milestones or a "bug group" change).  This generated a Load of email to a lot 
of folks.

While I would be happy to have a "don't send email" button to avoid this 
email, it would be just as useful for me if the recipients got a single email 
message containing the collection of changes.

Comment 16

[timeless]

that's what my comment was about. i still don't know if there's a bug for it.

Comment 17

[Joel Peshkin]

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

Comment 18

[Keith Tyler]

1. Let's face it. If the admin really really wants to change the status of 
bugs on the sly, s/he can just go into the DB and hack away. In fact they 
could just go in and blow the bugs away entirely with a few nice quick DELETE 
FROMs. If the only resistance to this enhancement is that there's too much 
potential for "abuse", then the next step should be to find a way to prevent 
admins from accessing the database. But after all, the definition of what 
is "abuse" should be up to the operators of individual sites.

2. If this ability were available via the UI, the bug change audit trail would 
still be there, allowing inspection for the surreptitious actions of the evil 
abusive admin to be available for inspection. Doing it via the DB overrides 
the audit trail.

3. The batch change process needs work. As I say in bug 236930, to move a set 
of obsolete bugs from NEW to CLOSED, you have to first RESOLVE, then VERIFY, 
then CLOSE (for some reason, in a mass-change situation, you can't go straight 
from RESOLVED to CLOSED like you can when editing bugs individually). This 
adds to the discouraging amounts of email that get spit out in this situation.

Comment 19

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 20

[Dave Miller [:justdave]]

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.

Comment 21

[Onno Garms]

(In reply to comment #16)
> that's what my comment was about. i still don't know if there's a bug for it.

Having searched the database and not found such a bug, I added Bug 261771

Comment 22

[Mayuresh Rajwadkar]

HI

I am not sure but, all admins may not be well versed enough to go and handle 
sql databases. It would definately help if there is a functionality to move the
bugs around without sending out emails, especially for the admin.


Mayuresh

Comment 23

[Keith Tyler]

I should note that one workaround that I've discovered (while performing a large
manual recovery of the bug system) is to disable the "processmail" script (such
as with an "exit();" call on the first line). But of course, this should only be
done if you know you will be the only person using the system during that time.
This doesn't provide a true individual-basis solution.

Comment 24

[Keith Tyler]

(In reply to comment #23)
> I should note that one workaround that I've discovered (while performing a large
> manual recovery of the bug system) is to disable the "processmail" script (such
> as with an "exit();" call on the first line). But of course, this should only be
> done if you know you will be the only person using the system during that time.
> This doesn't provide a true individual-basis solution.

Note that the above workaround will introduce Bug 278906.

And then I noticed a line in BugMail.pm:

# disable email flag for offline debugging work
my $enableSendMail = 1;

Turning this to 0 turns off email sending in a way that obviates the above
workaround and its problems.

Comment 25

[Joel Peshkin]

There are lots of ways to turn off mail system-wide.  However, the sites that
need this most are the huge sites that would least be able to accept losing all
bugmail during the discreet operation.

It should be possible, now, to pass a session-specific flag that overrides the
choice of Mailer and causes it to get sent to the bit bucket (or to testfile,
anyway)

Comment 26

[Keith Tyler]

The rampant fears about secrecy over lack of bugmail are unwarranted. All bug
changes are still tracked internally in Bugzilla, and can be viewed via the
"View Bug Activity" link on any bug. Turning off mail won't change that audit
trail. What it will change is the amount of "Bugzilla spam" that developers get
when a mass change has to be made for whatever reason.

The bottom line philosophy is: Don't tell the end-user admins how to run their
sites via code enforcement. 

(The feature to turn off mail on a change-by-change basis could be controlled by
an install-time or server-side setting; and made available only to site admins,
etc. This would be enough to prevent "abuse".)

Comment 27

[u197037]

Attachment: Allow suppress email on mass-change

This patch allow users in editcomponents group to suppress BugMails on mass-change.

Comment 28

[Frédéric Buclin]

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

Comment 29

[Frédéric Buclin]

Comment on attachment 202999 [details] [diff] [review]
Allow suppress email on mass-change

>--- /home/bugzilla/live/Bugzilla.pm

>+my $_nomail;

This parameter needs POD, especially because it contains a negation in its name and makes it unclear on how it works.


>--- /home/bugzilla/live/process_bug.cgi	2005-10-23 10:13:29.000000000 -0700
>+++ ./process_bug.cgi	2005-11-04 04:28:46.000000000 -0800

>+    # Remember current 'nomail' status before setting the new one
>+    my $nomail = Bugzilla->nomail;
>+
>+    # Double check nobody put 'nomail' parameter into the URL
>+    Bugzilla->nomail($cgi->param('nomail') ? 1 : 0) 
>+        if (UserInGroup("editcomponents"));
>+
>+    Bugzilla::BugMail::MessageToMTA($msg) if (!$nomail);

So if I understand this correctly, you don't call MessageToMTA() at all if $nomail = 1, independently of $cgi->param('nomail'), right? In other words, you allow to override the current behavior only if you can initially send emails? If that's the desired effect, please add a comment to explain this and why. Else fix the code and add a comment anyway. ;)

One more thing: You added the checkbox when changing several bugs at once only, but I could easily hack the URL to set this param in all cases.

Comment 30

[Olav Vitters]

Comment on attachment 202999 [details] [diff] [review]
Allow suppress email on mass-change

>--- /home/bugzilla/live/Bugzilla.pm	2005-10-18 09:11:17.000000000 -0700
>+++ ./Bugzilla.pm	2005-11-04 04:29:26.000000000 -0800
>+my $_nomail;
>+sub nomail {

Will this work with mod_perl? I see that the flag will be rest if the user has editcomponents, but I'm pretty sure that with mod_perl this will be remembered. I know Bugzilla doesn't support mod_perl, but I rather have the flag passed correctly using $vars in process_bug.cgi (e.g. new argument to SendBugMail in template/en/default/bug/process/bugmail.html.tmpl, etc). Without this flag passed the correct way + mod_perl mail could be disabled for process_bug.cgi, but also importxml.pl,  post_bug.cgi, etc.

Comment 31

[u197037]

(In reply to comment #29)
> (From update of attachment 202999 [details] [diff] [review] [edit])
> >--- /home/bugzilla/live/Bugzilla.pm
> 
> >+my $_nomail;
> 
> This parameter needs POD, especially because it contains a negation in its name
> and makes it unclear on how it works.
Ok, POD section is added in a manner of batch item.

> >--- /home/bugzilla/live/process_bug.cgi	2005-10-23 10:13:29.000000000 -0700
> >+++ ./process_bug.cgi	2005-11-04 04:28:46.000000000 -0800
...
> >+    Bugzilla::BugMail::MessageToMTA($msg) if (!$nomail);
It's just redundant and meaningless right now (though not affect the behaviour). The real value of Bugzilla->nomail is checked in MessageToMta(). So, I remove this check.

> One more thing: You added the checkbox when changing several bugs at once only,
> but I could easily hack the URL to set this param in all cases.
> 
Well, this will affect only Param('move-button-text') action and ONLY for users in editconponents group. Could this action be performed not only for mass-change? Should I add a checkbox into some other template? Or should I check somehow for mass-change case?

Comment 32

[u197037]

(In reply to comment #30)
> (From update of attachment 202999 [details] [diff] [review] [edit])
> >--- /home/bugzilla/live/Bugzilla.pm	2005-10-18 09:11:17.000000000 -0700
> >+++ ./Bugzilla.pm	2005-11-04 04:29:26.000000000 -0800
> >+my $_nomail;
> >+sub nomail {
> 
> Will this work with mod_perl? I see that the flag will be rest if the user has
> editcomponents, but I'm pretty sure that with mod_perl this will be remembered.
> I know Bugzilla doesn't support mod_perl, but I rather have the flag passed
> correctly using $vars in process_bug.cgi (e.g. new argument to SendBugMail in
> template/en/default/bug/process/bugmail.html.tmpl, etc). Without this flag
> passed the correct way + mod_perl mail could be disabled for process_bug.cgi,
> but also importxml.pl,  post_bug.cgi, etc. 
Well, I am not clearly understand of variables scope in mod_perl case. All I did is just follow the batch() model.

Comment 33

[u197037]

Attachment: Commented patch w/o mod_perl support

Frederic, I've added some comments and pod section. Also, reworked a bit checks in process_bug.cgi to reduce times Bugzilla->nomail is called.

Comment 34

[Frédéric Buclin]

Comment on attachment 203267 [details] [diff] [review]
Commented patch w/o mod_perl support

>Index: Bugzilla.pm

>+sub nomail {
>+    my $class = shift;
>+    my $newval = shift;
>+    if ($newval) {
>+        $_nomail = $newval;
>+    }
>+    return $_nomail || 0;
>+}

This doesn't work. Assume you want to stop sending emails:
Bugzilla->nomail(1) => $_nomail = 1
Now you want to reenable emails:
Bugzilla->nomail(0) => $_nomail = 1 anyway!

The correct test is: if (defined($newval)).



>Index: process_bug.cgi

>+    my $nomail_new = $cgi->param('nomail') ? 1 : 0;
>+
>+    # Double check nobody put 'nomail' parameter into the URL while not in
>+    # editcomponents group. Also, do not change current 'nomail' status unless
>+    # requested explicitly.
>+    Bugzilla->nomail($nomail_new) 
>+        if ($nomail_new && UserInGroup("editcomponents"));

Problem: assume that emails are disabled and that you want to enable them here. How do you do that?? $nomail_new = 0 (because you want to send emails) but Bugzilla->nomail($nomail_new) is called only if $nomail_new = 1 and the user has the correct privs. So this code only allows you to disable emails, not to enable them. As I said in my previous review, if that's the expected behavior, I want to see a comment saying so.


>+    # Restore 'nomail' status under the same restrictions as it was set above.
>+    Bugzilla->nomail($nomail_old)
>+        if ($nomail_new && UserInGroup("editcomponents"));

No need for a test. You can safely call Bugzilla->nomail($nomail_old) in all cases.

Comment 35

[u197037]

Attachment: Fixed bug in nomail() + some more text in comments

(In reply to comment #34)
> (From update of attachment 203267 [details] [diff] [review] [edit])
> >Index: Bugzilla.pm
> 
> >+sub nomail {
> >+    my $class = shift;
> >+    my $newval = shift;
> >+    if ($newval) {
> >+        $_nomail = $newval;
> >+    }
> >+    return $_nomail || 0;
> >+}
> 
> This doesn't work. Assume you want to stop sending emails:
> Bugzilla->nomail(1) => $_nomail = 1
> Now you want to reenable emails:
> Bugzilla->nomail(0) => $_nomail = 1 anyway!
> The correct test is: if (defined($newval)).
Thanks, I've missed that. Fixed.

The same problem might be in batch() code a few lines below. Should I fill a bug? (But I do not aware of actual usage pattern.)

> >Index: process_bug.cgi
> 
> >+    my $nomail_new = $cgi->param('nomail') ? 1 : 0;
> >+
> >+    # Double check nobody put 'nomail' parameter into the URL while not in
> >+    # editcomponents group. Also, do not change current 'nomail' status unless
> >+    # requested explicitly.
> >+    Bugzilla->nomail($nomail_new) 
> >+        if ($nomail_new && UserInGroup("editcomponents"));
> 
> Problem: assume that emails are disabled and that you want to enable them here.
> How do you do that?? $nomail_new = 0 (because you want to send emails) but
> Bugzilla->nomail($nomail_new) is called only if $nomail_new = 1 and the user
> has the correct privs. So this code only allows you to disable emails, not to
> enable them. As I said in my previous review, if that's the expected behavior,
> I want to see a comment saying so.
I've added comment stating "Also, do not change current 'nomail' status unless requested explicitly."
Isn't it enough? The only possible action on that particular form is to disable sending e-mails for that particular action. 
Anyway, I'll add some text like "It's impossible to enable emails if they are disabled at the moment"

> >+    # Restore 'nomail' status under the same restrictions as it was set above.
> >+    Bugzilla->nomail($nomail_old)
> >+        if ($nomail_new && UserInGroup("editcomponents"));
> 
> No need for a test. You can safely call Bugzilla->nomail($nomail_old) in all
> cases.
Ok. Removed. Comment re-written.

Comment 36

[Frédéric Buclin]

Comment on attachment 204352 [details] [diff] [review]
Fixed bug in nomail() + some more text in comments

>Index: process_bug.cgi

>+    # Checkboxes do not have values, so check for parameter presence in HTTP
>+    # request params.
>+    my $nomail_new = $cgi->param('nomail') ? 1 : 0;

Nit: no need for this comment. We all know how checkboxes work (or at least we should).


>+    # Double check nobody put 'nomail' parameter into the URL while not in
>+    # editcomponents group. Also, do not disable e-mail status unless requested
>+    # explicitly. It is not intended to enable e-mails if they are disabled at
>+    # the moment.
>+    Bugzilla->nomail($nomail_new) 
>+        if ($nomail_new && UserInGroup("editcomponents"));

Nit: You could as well write Bugzilla->nomail(1) directly as it's the only value which will be passed if the test is true.

>+
>     Bugzilla::BugMail::MessageToMTA($msg);
> 
>+    # Restore 'nomail' status. It's safe to restore it unconditionaly.
>+    Bugzilla->nomail($nomail_old);

Note that you put this code in the wrong place. You are disabling emails when MOVING bugs to another database, which is not what you want (emails must be sent in this case, always). Look at the end of process_bug.cgi instead. ;)



>Index: template/en/default/list/edit-multiple.html.tmpl

>+[% IF user.groups.editcomponents %]
>+<br>
>+<input name="nomail" type="checkbox">Supress E-Mails on mass change</input>
>+<br>
>+<br>
>+[% END %]

</input> doesn't not existin the HTML 4.01 Spec! You have to use
<label for="nomail"></label> and add id="nomail" to <input> as the label will be looking for it. Also, please fix the indentation.

Comment 37

[Olav Vitters]

Dennis: Ping. Please post a new patch/reply. If not, I'll reassign it to me in about 1 week (interested in this as well).

Comment 38

[timeless]

*grumble* view bug activity is a royal pain when you're trying to stalk millions of bugs. as it happens i'm only stalking around a quarter million on one bugzilla install, but i am stalking a number of installs. the concept is broken, bugzilla is about subscribing to get mail. if people don't want mail they should opt not to get it. if you want an extra setting in mail prefs [x] give me mail for mass changes, and you want to make that default to unchecked, fine. but don't steal mail from me. i know quite a few people who seem to like to turn on bugmail. i get and user more bugmail than most people in the world, and i can use it. you shouldn't be taking it away from me.

yes i know that admins can do whatever they want, but that doesn't mean that they should. nor does it mean that admins are likely the ones trying to make changes. usually it's someone else who isn't an admin and who can't do things that admins can do.

Comment 39

[Olav Vitters]

(In reply to comment #38)
> if you want an extra setting in mail prefs
> [x] give me mail for mass changes
> and you want to make that default to unchecked,
> fine. but don't steal mail from me.

Will ask others to comment on that.

Comment 40

[Frédéric Buclin]

We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.

Comment 41

[Joshua Thomas]

As a user of bugzilla at a software company, I frequently do mass-changes that end up sending dozens or hundreds of bugmails. This is highly annoying to people CCed on those bugs.

We're ok with a 'discreet' option for mass-changes; the history of the bug is always there for review.

Comment 42

[Marc Schumann [:Wurblzap]]

What I'm thinking is that we could have some kind of checkbox on the mass edit form to mark the edit as an "administrative bulk change" or something. And we should allow users to opt in and out of such "administrative bulk change" mailings via a setting.

I'm liking this to Mediawiki's feature to suppress information about so-called "minor edits", which an editor can mark an edit as.

Comment 43

[Jonathan Hansen]

Short version: Me too! On granular notifications in user profile.

Long explanation of short version:

As the recipient of Josh's mass changes (See Comment #41) and basically the dumping pot for two groups bugs, I would have to agree that an "opt out" of different sorts of notifications on a more granular level would be a good thing.

For instance, bugs opening I care about, bugs closing I don't as it is already off my plate by that time.
Bugs being re-assigned is not relevant to me as I still have to track them, so I want to see comments, but not the change in ownership if that makes sense.

If one of these buttons was "mass changes" so you could ignore them it would be wonderful.

Comment 45

[Max Kanat-Alexander]

The right solution to this (I thought there was another bug, but I didn't find it) is to send just one email for the entire mass-change. The top of the email will state what changes were requested by the user, and below that will be a single listing for each bug of what actually changed (though the comment will only appear once, if there is a comment).

Comment 46

[Matthew Tuck [:CodeMachine]]

Bug #26943 is the original bug.

Comment 47

[Frédéric Buclin]

(In reply to comment #46)
> Bug #26943 is the original bug.

Yes, we already have this one. Resetting the bug summary to its inital state as the new one is totally out of topic with the discussion here. So implementing the ability to block bugmails for some changes is WONTFIX in favor of bug 26943.

Comment 48

[Keith Tyler]

http://confluence.atlassian.com/display/JIRA/Modifying+Multiple+%28%27Bulk%27%29+Issues#ModifyingMultiple%28%27Bulk%27%29Issues-DisableMailNotificationforBulkOperations

BZfail. The devs know better than the users.

Comment 49

[Matthew Tuck [:CodeMachine]]

> BZfail. The devs know better than the users.

That's funny, I thought it was users who were concerned that they wouldn't receive bugmails they care about.  I used Bugzilla on a daily basis for many years, and bug #26943 was always the real problem (especially after notification preferences were introduced).

What's the point of introducing notification preferences if someone else can ignore them?  The only thing that might make sense is an "insignificant" checkbox and let receivers decide whether they want to receive based on it, but I think that would possibly still be overkill.

Comment 51

[Damien Nozay [:dnozay]]

https://wiki.mozilla.org/Bugzilla:Addons#Bugzilla_Extensions

MultipleEditNoEmail Provides a checkbox to not send email when changing multiple bugs at once, disregarding user preferences, user watching and global watchers. To be used for miscellaneous bug updates.

https://github.com/dnozay/Bugzilla-Extension-MultipleEditNoEmail

Comment 55

[Craig]

 This feature would be REALLY, REALLY, REALLY helpful. I am involved with an implementation where we are redefining the statuses, priorities, and product-component tree and changing hundreds of records at once.

As an Administrator, I'd like to turn off the notifications for ticket changes by my account until the high volume of changes is complete. We encouraged users to adjust down their notifications, but they still get hundreds of e-mails.

In Quality, we call unwanted information noise. Noise, like spam, costs money and time.

The logic would be something like:
Under site preferences, add a toggle for Stealth Change.
If Usertype=Admin AND if SiteStealthChange=Yes, enable field UserStealthChange under user E-mail Preferences.
If UserStealthChange=Yes, do not send any e-mail notifications for ticket changes.

Comment 56

[Craig]

I just looked up and saw the Extensions for this feature. Thank you Damien for posting!

Comment 58

[Ed Morley [:emorley]]

This is now being implemented in bug 1062718.