Bug 267349

Summary: extension: Ability to suppress mail for issue changes (individual and bulk)
Product: Services Reporter: Kubilay Kocak <koobs>
Component: Bug TrackerAssignee: Bugmeister <bugmeister>
Status: Open ---    
Severity: Affects Many People CC: bugmeister, grahamperrin
Priority: Normal Keywords: needs-qa
Version: unspecified   
Hardware: Any   
OS: Any   
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=26943
https://bugzilla.mozilla.org/show_bug.cgi?id=1062718
https://bugzilla.mozilla.org/show_bug.cgi?id=1134528
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227147
Bug Depends on:    
Bug Blocks: 198388, 254064, 254729, 191430    
Attachments:
Description Flags
Bugzilla 5.0 suppress mail patch (github/keto) none

Description Kubilay Kocak freebsd_committer freebsd_triage 2022-10-26 00:05:42 UTC
Making "mass" changes to existing issues, particularly during or after schema/classification changes, such as adding/removing/merging products, components, keywords, etc results in every modified issue sending out email for every change. 

This results in a ridiculous amount of email being sent out to every recipient/participant on an issue, in a very short period of time, often to mailing lists (as they are default assignees for many products/components), for what in many cases are changes that ought not require notification, as the change is at the issue metadata level, rather than issue 'content' or substance level, that people on an issue might want to be notified of.

The current behaviour being so visible and annoying to recipients of that email, puts up *significant* barriers to bugmsiter confidently and quickly making schema changes and improvements, which require updating large numbers of issues to fit/match the updated schema.

Imagine for example (and there are countless examples):

- Adding a new Component:dtrace

We'd want to search all issues containing dtrace/[dtrace]/etc in the title and add them to the new Component, where a component wasn't, or was imprecisely set before (eg: kernel).

In order to unblock progress on at least some very obvious schema improvements, as well as to encourage even better schemes, we need to the ability to mass change issues without worrying about torrents of email being sent out.

Upstream has received requests for this kind of feature in various guises and implementations for a long time:

https://bugzilla.mozilla.org/show_bug.cgi?id=26943
https://bugzilla.mozilla.org/show_bug.cgi?id=1062718
https://bugzilla.mozilla.org/show_bug.cgi?id=1134528

It remains unclear if any existing/wip upstream implementation is going to be useful for the cases we need it. Not withstanding, I believe it'll only become available in future Bugzilla versions, at an unknown time (and very unlikely not 5.x. series).

Other bugzilla users have created 'patches' or extensions to provide this functionality at least at some level. I document one here:

   Bugzilla 5.0 suppress mail patch (github/keto)
   https://gist.github.com/keto/bbb09ea3e876f7272c44a9ce7e229d79

Code hasn't been reviewed in detail, but it appears to add a permission group for 'suppressing mail' and a checkbox to the edit (individual) bug template, to prevent sending out mail prior to submitting a change.

We'd also need:

- Ability to suppress mail in the bulk edit case (at least)
- Ability implemented entirely as an extension, if possible, not code patches that we would need to maintain, and potentially merge/fix during future upgrades, which we'd like to avoid.

Of the list of things that would promote progress within Bugmeister, along with automated deployments, is this feature and improved extensions
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2022-10-26 00:07:52 UTC
Created attachment 237634 [details]
Bugzilla 5.0 suppress mail patch (github/keto)
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2022-10-26 00:12:06 UTC
See Also: bug 227147 'was' blocked and affected by this (see bug 227147 comment c14), but we bit the bullet to make the change absent this feature.