886775 - "Change several bugs at once" should allow suppressing bugmail

Status: RESOLVED DUPLICATE of bug 23924

(Bugzilla :: Email Notifications, enhancement)

Description

[Jens Bannmann]

It would be great if the "change several bugs" page offered a checkbox like "Suppress bugmail for this change". This would be useful for "global" changes everyone knows about anyway, so you don't want to create bugspam (which could "train" users to ignore bugmail in general).

Example: we decided to skip version 1.0.1 and call the next release 1.1 - however, simply renaming the milestone would not appear in each bug's change history, and furthermore was not possible in our case, as 1.1 was already created earlier.

Workaround: edit all user accounts to disable bugmail (which doesn't work well if you have more than a handful users).

Comment 1

[Andre Klapper]

Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

Comment 2

[Jens Bannmann]

I don't agree that this is a duplicate. "Send one mail instead of several" is vastly different to "Allow disabling bugmail for one change". In my example above, each individual user did actually get only one mail.

Of course, reducing the number of emails sent to 1 instead of 0 would improve the situation for most other scenarios where "bugspam" hurts users.

Still, I propose that this feature is kept separate from bug 26943, as that bug is vastly more complex, has been open for years and to me does not look like it's going to be fixed very soon or very easily. In contrast, this bug might actually be very simple to implement.

Would a patch be accepted for this?

Comment 3

[David Lawrence [:dkl]]

I agree that this a different issue than bug 26943 so reopening. 

As for this request, I can see the utility in having a checkbox for disabling email for mass changes in certain circumstances. We (BMO admins) do have to make mass changes when moving bugs from one product/component to another and we do so now with custom scripts to keep emails from being sent. Being able to do this through the UI would be helpful.

But I am not sure that this option should be available to the mass public. At a minimum the user the would need at least 'editbugs' rights but I feel it should be higher than that. Certain bug changes I am sure the user would not want to be suppressed and should be able to get emails when their bug has been changed. That is why each user has their own email preferences. For example if you mass close a set of bugs I would think the reporters would want to know that. So we would either need to limit the type of changes that can be suppressed or make it a privilege to be able to suppress and to be used with care and pre-thought.

Any others have thoughts on this?

dkl

Comment 4

[bigstijn]

Maybe bug 167533 should then be duplicate of this bug, and not of bug 26943 .

Comment 5

[Frédéric Buclin]

This is a duplicate of bug 167533, which has been marked as a duplicate of bug 26943.
See also bug 221777, which has been marked as wontfix. The reasoning is that we don't want to let the user doing changes decides what is important and what is not, and what should trigger bugmails and what shouldn't. Users have email preferences to decide what they want to get or not.

Personally, I would hate to see changes in a bug, e.g. assigned to me, for which I didn't get any email notification. It's easy enough to filter such bugmails from your email client so that you can easily delete them all at once if you want to. Personally, this bug is WONTFIX, as it would be abused by (power) users.

Comment 6

[Jens Bannmann]

(In reply to Frédéric Buclin from comment #5)
> See also bug 221777, which has been marked as wontfix. The reasoning is that
> we don't want to let the user doing changes decides what is important and
> what is not, and what should trigger bugmails and what shouldn't.

Please note that bug 221777 was about a general option for single-bug changes. Bulk changes are an entirely different thing.


(In reply to Frédéric Buclin from comment #5)
> Personally, this bug is WONTFIX, as it would be abused by (power) users.

I'm not convinced by your reasoning, Frédéric. The distinction between use and abuse is made by each organization using Bugzilla, and thus to the admins setting it up. This does not mean we should implement any weird feature one person on the planet suggests, but we should consider those that
1) have been asked for multiple times and
2) make Bugzilla adapt better to different ways of working.

Point 1) seems clear given the different dupes mentioned.

Point 2) As outlined above, at my company we all agree to restrict bugmail to an absolute minimum. Also, in comment #3, David gives a real-world example from Mozilla practice, so the feature is probably not the craziest idea. Also, the fact that Atlassian JIRA supports this may be evidence that it's useful to some organizations.

In the end, not offering UI for this situation simply means we force admins to write their own (possibly faulty) scripts. Do we want that?

However, I do agree that suppressing mails should not be allowed for everybody in every installation of Bugzilla (not even everybody with EDITBUGS). Restricting this to users with administrative rights would be sufficient for the mentioned use cases. Still, the feature could be disabled by default and enabled with a core parameter.

Comment 7

[Damien Nozay [:dnozay]]

Jens, here is the update I made on bug 23924:

> 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

This doesn't handle groups and who's allowed to see/use this checkbox, but could provide you with a start.

--

I agree that there is potential for abuse, but that doesn't mean the code should prevent/discourage such use case, bugmail/email is not the first class citizen in some organizations; hence providing an extension should allow admins to use best judgement and enable it if they really want it.