在 bugzilla 中同时修改多个错误时禁用电子邮件

发布于 2024-08-30 20:41:37 字数 189 浏览 4 评论 0原文

在我工作的地方,我们广泛使用 Bugzilla 来跟踪错误和功能。我们利用内置的里程碑来帮助我们更好地管理时间表,但有时优先级会发生变化,里程碑需要重新安排。在此期间,我们使用“一次更改多个错误”功能来移动它们,但结果是每个参与人员都会收到大量错误垃圾邮件(当然,实际进行更改的人除外)。

如果同时更改许多错误,是否有任何方法可以轻松关闭电子邮件?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

樱桃奶球 2024-09-06 20:41:37

可以,但需要管理员权限。在“管理”部分中,转到“参数:电子邮件:mail_delivery_method”并将其设置为“测试”(将电子邮件假脱机到磁盘上的文件)或“无”(完全禁用电子邮件)。然后,进行更改并重新启用您的电子邮件。您可能希望在 announcehtml 中添加一条消息,以便使用该系统的任何其他用户都知道在您更改错误时不会发送任何电子邮件。

您还可以说服用户(和/或设置默认选项)取消选择电子邮件首选项中在“优先级、状态、严重性或里程碑发生变化”时发送电子邮件的选项。

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."

无所的.畏惧 2024-09-06 20:41:37

五年后,此功能已提交给 Bugzilla 的 master 分支(2015 年 3 月 13 日,提交 1d96fa1),目前正在跟踪 Bugzilla 6.0 的交付情况

此功能请求存在多个错误,但实际修复的是 错误#1062718

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

此刻的回忆 2024-09-06 20:41:37

不幸的是,这并不容易。最好的办法是发送有关如何设置电子邮件首选项的明确说明,以便不会生成有关这些事件的电子邮件。我想你可以更新他们的偏好。

您可以通过几种方式在代码中实现您想要的内容。例如,您可以向 process_bug.cgi 添加逻辑,以便不为这些事件生成电子邮件。

我们在非常旧的 Bugzilla 中添加了一个复选框 template/en/default/list/edit-multiple.html.tmpl ,允许“安静”的更改,直到下次修改 bug 时才生成电子邮件。新的错误电子邮件会发送自上次差异以来更改的所有内容,因此如果不更新上次差异,更改最终将消失。

然而,我想说服你不要做这些!我不愿意使用我们添加的安静更改复选框,因为这意味着我正在用我的判断代替每个可能的接收者的判断。我想这对于里程碑等来说是可以的,但总的来说,我想尊重每个用户的偏好。

如果您决定在代码或模板中实施一些更改,您应该访问 irc.mozilla.org 上的 #mozwebtools 来讨论它们,看看是否存在具有候选补丁的相关错误等。

我们所做的另一个不在 Mozilla 版本中的是我们为每封外发电子邮件添加标头,以便轻松过滤掉人们不想要的电子邮件。

不过,隧道尽头还是有一点曙光。我知道 Max Kanat-Alexander(以及其他主线贡献者)和我们都在考虑如何将对许多 bug 的一系列更改视为一个更改“集”。实施后,将“一次更改多个错误”合并到每个收件人的一封电子邮件中变得更加可行。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文