Disable email when modifying several bugs at once in bugzilla
Asked Answered
M

4

6

Where I work, we use Bugzilla extensively for bug and feature tracking. We take advantage of the built in milestones to help us manage our timelines better, but sometimes priorities shift and milestones need to be rearranged. During this time we use the "change several bugs at once" feature to move them around, but the result is a ton of bugspam for everyone involved (except the person actually doing the changing, of course).

Is there any way to easily turn off emails if many bugs are being changed at once?

Murdoch answered 26/4, 2010 at 17:17 Comment(0)
P
11

Yes, but it requires administrator access. In the Administration section, go to Parameters : Email : mail_delivery_method and set it to Test (to spool emails to a file on disk) or None (to completely disable email). Then, make your change and re-enable your email. You may want to put a message in announcehtml so any other users using the system will know that no emails will be going out while you are changing your bugs.

You could also convince your users (and/or set the default options) to deselect the option in the Email Preferences that sends email when "The priority, status, severity, or milestone changes."

Pharmacy answered 27/4, 2010 at 1:59 Comment(0)
M
4

Five years later, this feature has been committed to the master branch of Bugzilla (March 13, 2015 with commit 1d96fa1) and is currently tracked for delivery with Bugzilla 6.0

There have been several Bugs for this feature request, but the one where the actual fix happened is Bug #1062718

Minica answered 2/11, 2015 at 15:16 Comment(1)
FWIW, it's in the current Development Snapshot (5.1.2).Gayla
F
2

This is the relevant bug, FTR: https://bugzilla.mozilla.org/show_bug.cgi?id=26943

Fakir answered 28/5, 2012 at 15:9 Comment(0)
M
1

Not terribly easily, unfortunately. Your best bet is to send out explicit instructions about how to set email preferences so that emails about those events are not generated. You could update their preferences for them, I suppose.

You could implement what you want in the code a few ways. For instance, you could add logic to process_bug.cgi not to generate email for those events.

We added in our very old Bugzilla a checkbox in template/en/default/list/edit-multiple.html.tmpl that allowed "quiet" changes that didn't generate email until the next time the bug is modified. New bug email sends out everything that changed since lastdiffed, so by not updating lastdiffed, the change will eventually go out.

However, I would like to convince you to do none of these! I am reluctant to use the quiet change checkbox we have added because it means that I am substituting my judgment for that of each possible recipient. I guess this is OK for milestones and such, but in general, I want to respect each user's preferences.

If you decide to implement some changes in code or templates, you should visit #mozwebtools on irc.mozilla.org to talk about them, see if there are related bugs that have candidate patches, etc.

Another we do that's not in Mozilla's version is that we add headers to each outgoing email that makes it easy to filter out emails that people don't want.

There's a little bit of light at the end of the tunnel, though. I know that both Max Kanat-Alexander (and others who are mainline contributors) and we are giving thought to how to consider a bunch of changes to many bugs as one change "set." When that is implemented, it becomes more feasible to combine "change several bugs at once" into exactly one email per recipient.

Merrell answered 26/4, 2010 at 19:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.