Closed Bug 14137 Opened 25 years ago Closed 17 years ago

Choose what bugs you're interested in getting notifications for.

Categories

(Bugzilla :: Email Notifications, enhancement, P3)

Product:
Bugzilla
Component:
Email Notifications
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 278455

People

(Reporter: CodeMachine, Unassigned)

References

(Depends on 1 open bug)

Details

Currently you receive report change notifications based on criteria that can
basically be described as "Me In CC".  It would be nice to be able to change
this so can set open ended criteria which don't rely on you having to see the
reports before receiving them.

For example, some people might be interested in reading notifications for
everything in the "layout" component, or all new enhancement requests.

The way to select which reports this applies to should reuse the query report
selection mechanism.

I would suggest that you should receive notifications if the selection applies
before OR after the change.
I agree this is a pretty cool idea.  I have two pragmatic problems with it:

(1) It's a lot of code to write, and I don't have the time.
(2) It doesn't quite scale.  To do this, I will have to run a query for every
person in the Bugzilla database for every bug that is changed.  mozilla.org
currently has 6883 people in its database.  To do 6000 queries every time a bug
changes is a bit much.  I suppose it could be optimized to only do queries for
people who have set up something unusual, but still, the potential of meltdown
is too great.
It could well have these problems.  You might try precomputing stuff in the
background, and you could certainly turn it off for large sites.  I'm not
convinced that we're talking about more than a couple of hundred queries for
the more advanced users who would use it.

"Meltdown" is a very emotive word.  Whether or not it works depends on the
implementation vs. the speed of the machine.  Any implementation of a bare bones
bug tracking system could fail if you put it under enough strain, there's no
black and white.

Whether it would work on Bugzilla, if ever implemented, remains to be seen of
course.

It's possible that it might be useful to do this in more restricted
circumstances.  Even if general selections are too much, you could
restrict this to more efficient, less flexible forms.

For example you could watch certain components, and I imagine this could be
efficiently looked up.

Or you could restrict this to queries of the form:

Field = Value AND Field = Value AND FIELD = Value

which feels like it would be more efficient since it's simply a matter of
maintaining a table of (user,field,value) pairs.  In this case, you run the
query once for each field, not once for every user, and extract the resultant
users.

Food for thought.
There are various issues with expressing this.  You want to be able to express a
condition to match which bugs to notify on (ie old OR new value is a specific
criteria) as well as what changes to bugs to notify on (ie not on dependency or
cc).

You could separate these concepts.  For example, you might be interested in
"resolution only" to only notify when a bug becomes resolved.  These might be
"notification classes" which you assign to bug groups or specific bugs.

Assumedly the specific setting would override the default setting as to whether
a bug is notified.

I put a comment on bug #37345 (BCC) about separating resolution only and normal
notification, and bug #17464 talked about settable change triggers to prevent
dependency spam.
Status: NEW → ASSIGNED
The amount of computing required would be vastly reduced if you restricted it 
only to those in the CC list ... That is, as I suggested in n.p.m.webtools, give 
each user a set of checkboxes for the fields they care about (defaulting to all 
checked, except the `Votes' checkbox, to reproduce current behavior). If a user 
is on the CC list for a bug, AND one of those fields changes, THEN they get a 
notification.

Yes, this report now covers both issues, and only the first (original) one about
choosing what bugs (rather than changes) delivers a notification has the
"meltdown" potential.
Each notification class could define a set of "keywords", for want of a better
term, that appears in the subject line for the criterion of this class.  This
could allow better and easier filtering than any "body search" since it is
Bugzilla specific.
Someone might well want to receive notifications about bugs added to a keyword,
this would be necessary to replace tracking bugs and their dependency
notification facility.
Please move the issue of which changes trigger a notification to bug #23925, as
it's probably simpler if this report is purely for choosing which bugs you're
interested in.
Summary: Set your own notification criteria. → Choose what bugs you're interested in getting notifications for.
Perhaps the queries could be run daily and only if the bug list (or some bug
attribute) changed the user would receive notification. This means keeping one
query state for each such query and running the queries once per day.

It would be a nice feature to have a previous result of a saved query saved and
the ability to generate a diff. (Save a new result should be optional)


tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Blocks: 53044
This bug blocks 53044, a tracking bug for email changes. Please have 
any email discussion on that bug instead of here.
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
OK, I have a plan.

Firstly, people always seem to want to sit on an individual field, not a
combination of them.  There are some situations where you want to sit on two
fields, but these seem to be where you want to sit on one field and the
product/component.  This is because the first field has product/component
specific values.

Examples are keyword watches (bug #34787), component/product watches, milestone
watches (product-specific), etc.  In all cases it is OR at the top level.  I
don't see that we need to provide full boolean logic.

So given this, we can have one table for each sort of watch we feel is valuable.

I'm not sure exactly how this should work in the BZ3 world.

And also, how we should order the watches so we can determine a notification
class for the user, which is important for bug #26943.
Perhaps ironically, this might reduce the instance of unwanted mail, because it
would reduce the use of the CC fields.  But maybe not so much when people can
turn the CC field off.
Target Milestone: --- → Bugzilla 3.2
Depends on: bz-component-watch
Depends on: emailprefs
Blocks: 86547
-> Bugzilla product, trying Email component, reassigning.
Assignee: tara → jake
Component: Bugzilla → Email
Product: Webtools → Bugzilla
Version: other → unspecified
No longer blocks: 53044
Depends on: 95255
Changing default owner of Email Notifications component to JayPee, a.k.a.
J. Paul Reed (preed@sigkill.com).  Jake will be offline for a few months.
Assignee: jake → preed
*** Bug 237295 has been marked as a duplicate of this bug. ***
I'd like to propose bug 278455 as the entire solution to this bug.
Depends on: bz-field-watch
Target Milestone: Bugzilla 3.2 → ---
Kick all my Bugzilla bugs back to the component default owner.
Assignee: preed → email-notifications
QA Contact: mattyt-bugzilla → default-qa
I know that this bug was filed earlier, and my bug was filed later, but my bug is a very specific solution to the very general problem described in this bug. It also works fine performance-wise, and does what people need it to do. It also has a WIP patch.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.