Closed
Bug 14137
Opened 25 years ago
Closed 18 years ago
Choose what bugs you're interested in getting notifications for.
Categories
(Bugzilla :: Email Notifications, enhancement, P3)
Bugzilla
Email Notifications
Tracking
()
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.
Comment 1•25 years ago
|
||
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.
Reporter | ||
Comment 2•25 years ago
|
||
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.
Reporter | ||
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 4•25 years ago
|
||
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.
Reporter | ||
Comment 5•25 years ago
|
||
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.
Reporter | ||
Comment 6•25 years ago
|
||
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.
Reporter | ||
Comment 7•25 years ago
|
||
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.
Reporter | ||
Comment 8•25 years ago
|
||
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.
Comment 9•25 years ago
|
||
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)
Comment 10•25 years ago
|
||
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
Comment 11•24 years ago
|
||
This bug blocks 53044, a tracking bug for email changes. Please have any email discussion on that bug instead of here.
Comment 12•24 years ago
|
||
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one. Sorry for the spam.
QA Contact: matty
Reporter | ||
Comment 13•24 years ago
|
||
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.
Reporter | ||
Comment 14•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Target Milestone: --- → Bugzilla 3.2
Reporter | ||
Updated•24 years ago
|
Depends on: bz-component-watch
Reporter | ||
Updated•24 years ago
|
Depends on: emailprefs
Comment 15•23 years ago
|
||
-> Bugzilla product, trying Email component, reassigning.
Assignee: tara → jake
Component: Bugzilla → Email
Product: Webtools → Bugzilla
Version: other → unspecified
Comment 16•23 years ago
|
||
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
Comment 18•20 years ago
|
||
I'd like to propose bug 278455 as the entire solution to this bug.
Depends on: bz-field-watch
Target Milestone: Bugzilla 3.2 → ---
Comment 19•19 years ago
|
||
Kick all my Bugzilla bugs back to the component default owner.
Assignee: preed → email-notifications
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 20•18 years ago
|
||
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: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•