It should be possible to specify a list of components to watch and to receive all email generated about bugs in those components, subject to the filtering rules specified in newemailtech. As a first cut, make it so watching a component is the equivalent of being cc:ed on every bug in that component, so the cc: filter rules apply to the email generated. Eventually, create a separate filter category for watched bugs like the one proposed in bug 74996. This bug might also address some of the issues in bug 69399.

-> myself

Sorry for the spam, folks, I think I finally figured out what I am supposed to be doing here. You'll get another spam from me in a bit.

Now that I have reassigned the bug I will accept it, finally accomplishing my goal of both the bug being assigned to me and it having the status "ASSIGNED". Move along folks, nothing to see here, nosiree.

some comments: 1) It has a nice javascript interface, but it also needs to be usable by people who don't have js or who have it turned off. 2) right now the code is implemented so that if you choose to watch a component "x", you get mail for bugs in all components named "x", no matter which product. If there is a component named "x" in 5 different products, you get mail for all 5 products. The watched component should be recorded as a product/component pair. There are a few duplicate component names on b.m.o. (localization, printing, core, preferences, 3) when component name is changed (and product too, if that's changable), it should update the name in the component-watch table.

OK, this is a part of the bug #14137 functionality ... please make sure you're familiar with the comments on that bug. In particular, I would be very wary of setting up a new notification prefs category. Firstly, you might want to set different component watches as different for different components, and you might want the existing categories to be identical. It is time we did something to stop this getting out of control ... and the only way to do it is let the user specify what categories should appear. Unfortunately this dictates that you should be able to specify something like "Component Watch On Foo and I am on QA list". This is probably the solution to user watch problems as well.

Having different filters for different components that are watched would be rather difficult in the current schema for filtering prefs. Perhaps this should be considered when implimenting bug 73665.

My latest patch modifies the UI so users with browsers that don't support JavaScript or who have turned it off can still edit their component watches. It also fixes the problem of components with the same name in different products by storing the product name along with the component name in the componentwatch table (along with corresponding changes in the UI so that every component being watched is associated with a product). Finally, when a product or component name is changed or that product/component is deleted the componentwatch table gets updated accordingly. Bug 14137 is a generalized watching system that this bug only partially addresses. If the potential performance issues in that bug were resolved and its recommendations implemented, that feature would supercede this more limited component watch. The question is whether the advantages of component watching is worth implementing now or whether it's better to wait for generalized watching to be implemented. Adding the ability to specify which list (owner, reporter, qa contact, cc list, voter) you would like Bugzilla to pretend you are on when you watch a component is a good idea that sidesteps the need for modifications to the mail filtering system (for now). I'm not sure if there is an easy solution for this, but if so I'd like it to side-step the issues in bug 73665 by adding component watchers to the various lists before the mails get processed and then piggybacking off the email preferences for those lists. This way no changes in the filtering code are necessary at all for implementation of component watching and that bug can be dealt with on a separate timeline. It also allows us to test component watching on users and get their feedback on whether more finely grained filtering is necessary before implementing it.

Is there already a bug somewhere to use IDs for products and components? I have looked around a bit without success. Don't know if we want this, but the rule of thumb is to never duplicate textual information when used as reference to an entry in another table, isn't it?

I'd probably phrase that as whether the name is a part of the identity of the object. I wouldn't consider it so for components or products.

>Is there already a bug somewhere to use IDs for products and components? Bug 43600 >Don't know if we want this, but the rule of thumb is to never duplicate textual information when used as reference to an entry in another table, isn't it? Not necessarily. Arbitrary integer keys have both advantages and disadvantages over keys composed of record data like text names. On the one hand they take up less disk space and decrease the number of tables that have to be modified in updates, but on the other hand they can increase the number of tables that have to be joined in selects (which take place much more often than updates). So there are trade-offs in performance, disk space, and code simplicity to consider. In Bugzilla the name of a component does not identify that component uniquely since it is possible for two components in different products to have the same name. This means any table that references the components table has to include a column for not only the component name but also the name of the component's product. This adds enough code complexity that in this situation I agree with the reporter of bug 43600 that using an arbitrary integer key is the better approach.

See also bug 38922, "[RFE] Wanted: Default CC list for each component".

Would be nice if this also supported products (bug #53717). It seems a little silly to support one and not the other.

*** Bug 103845 has been marked as a duplicate of this bug. ***

What's left to do here? We have a patch, that has not been obsoleted; myk, is it still up to date? This feature will be very useful, since right now in order to follow a specific component's bugmail you either need to watch all the default assignees (and get all unrelated bugmail) or nothing at all.

Architecturally, this might be waiting on bug #73665. Or it might be waiting on product watching.

IMHO the right way of implementing this is by implementing the "Default CC list" idea of bug 38922 and then adding the ability for people to add/remove themselfs to/from those lists. This is better than doing it "directly" since - this allows people to remove themselves from the CC list of a particular bug they found uninteresting (or generating too much traffic) while still watching the rest of the bugs in the component - makes it more explicit - people would not waste time adding their collegues onto the CC list not knowing they are already on the watchers list.

Aleksey's suggestions sounds like the ideal way, to me, to fix this!

*** Bug 109257 has been marked as a duplicate of this bug. ***

I don't agree with the CC list comments. CC lists are big enough already, and they don't allow us to change our settings on existing bugs. I don't have problems with functionality to change certain types of bugs, but don't think this is the right way. A better way would be introducing and allowing filtering on personal keywords, which are more general besides.

CC lists are nice because they give a way for admins to supply a default list. Once we have soch default CC list, it's natural to want to give people an ability to add/remove themselves to/from the list. Another advantage of CC lists is that you can always see the CC list, so you don't need to waste time adding somebody to CC list just because you are not aware [s]he is already subscribed to the bug through some other mechanism. > CC lists are big enough already So? > they don't allow us to change our settings on existing bugs On the contrary - they do and that's another advantage - you can always remove yourself from a CC list of an existing bug without having to "unsubscribe" from the product/component. It's possible that something more general would still be needed, but I believe that the editable default CC lists should be implemented first and then we can see what kind of functionality is still missing. But even if we have some general functionality, i believe that the per-component default CC lists would still be needed - IMHO many users would find them easier to maintain and more intuitive than some general filters.

I also oppose the default CC list idea. I agree with MattyT when he mentioned CC lists being large enough. The reason why just adding people arbitrarily to CC lists is a bad thing is because it takes up space in the database. We are trying to use as little storage space as possible, though we realize that with this system (and especially by b.m.o) it can take up quite a bit of space. However, we save more space by querying against a watch list than a CC list. Whereas a component can have thousands of bugs, if you watch the component, you are in the DB once. If you get added to the CC list on each of them, well that's thousands of bytes you've wasted - for one user. It adds up quickly on large installs such as this, which may not be the best reason, but it's a good reason nonetheless. I'm not sure as to how large the database will balloon, but I would imagine it wouldn't exactly come cheap to do this. Also, from what i understand, the purpose of watching is for you to be able to watch transparently, so that others who might watch you don't get mail on things you watch. By adding me to the CC list, anyone who watches me gets that email as well, which is not how it should be IMO. "Quis Custodiet Ipsos Custodes" -Iuvenalis, Saturae, VI.

I agree that we shouldn't bloat the bugzilla db, but the downside of not adding the watchers to the default CC list would be that you cannot remove yourself from one single bug. Perhaps you could solve this by making bugzilla think that by default a watcher of a component is on the CC list, so once you're watching a component, you'll be added to all existing/future CC lists, but if you un-CC yourself, bugzilla's db would think "all CC lists except for bug X". That way you solve the bloat problem...

maybe we need an anti-CC list, which counters the effects of watching on a per-bug basis...

Grrr ... If people want to be able to opt out of specific bugs they can still use CCs and not watching. Eventually I think personal keywords can be used for an anti-CC list, I don't think it's worthwhile introducing a feature specifically for it. I don't have a problem with a default CC list but it's not going to solve this problem. I'm not too concerned with DB bloat, although that's always an issue. What I am concerned about, is that I'm watching a component, I will be on the CC list of every bug on the product. I don't want to have to resort to mass changes or such to have to change my watch preferences. If I change my watch preferences I want my watches to update. Step one won't be optimal, but it will be on the right path to optimal. Let's not go down the wrong path. If we really need anti-CC (and I doubt many of us do), we can implement personal keywords. We want them anyway.

The thing that hasn't been mentioned yet is filtering preferences. Once this is impliment correctly, each watch will have its own prefs. For instance, you could watch "Browser-General" and only get mail on bugs when they are first filed (once bug 69399 is also fixed) and watch "chatzilla" only receiving mail when bugs are resolved. I agree that default cc lists (bug 38922) can be useful, but I personally find this more useful.

OK, I see the following options here: (1) Admin-only initial CC lists - bug 38922 (2) Ability for users to add/remove them to/from initial CC list (depends on "1") (3) Ability for users to add/remove them to/from CC list of all bugs of a particular component w/o sending out any spam (possibly as an option when doing "2" or as a separate thing). (4) Ability to watch only new bugs - bug 69399 (5) Personal keywords, etc. Note that "DB bloat" only happens when 1-3 are actively used (e.g. people who prefer "4" and/or "5" do not cause it) and it is a price we pay for opt-out option. Also, it seems to me that this discussion does not make a necessary separation between "what we want is Bugzilla source code" and "what we want enabled on Mozilla.org". I would imagine that at least 1 and 2 would be quite useful in smaller Bugzilla installations while mozilla.org may need something more complex - e.g 3-5...

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

Dave told me to come here to discuss this bug. This is rather long winded and perhaps not terribly clear, but here goes: I needed something similar to this while converting an existing bug system over to Bugzilla. One of the thing that the old bug system does is that if you assign a bug to a particular product or component, in addition to a default engineering owner, it assigns a predetermined group of interested people to the e-mail notification. I had examined a whole bunch of ways to do this (adding a new table, adding new rows, etc) and I believe I have come upon a way to do this that isn't that invasive. First, I make the assumption that we only want to add the list of interested parties to a bug at bug creation time. Secondly, they should be added to the official cc list so that they can be added and removed from the notification list like normal. Third, that the list of people that are automatically pre- pended to the cc'list would fall under component administration: I.E. only a component admin can add or remove names from the default cc list. So what I did was I added an index field to the components table. This allows me to reference a single product/component combo by an integer number. Next, I opted to use the watch table, but instead of using positive number for the watched column, I used a negative number to identify components. So the watch table now looks like watcher watched 15 40 15 -1 By using negative numbers, you are assured of never colliding with real userids. Whenever a new bug is created, we first do a query on the component table, looking for the product and component that was selected. Then we get the index number for that component. You flip the number to be negative, then do a select of the watchers table on that negative index number, giving you a list of watchers on that component. You stick that into the ccids and away you go. Theoretically, it shouldn't be hard to add a UI for this in the watchers table. When you select everything a watcher is watching, when you encounter a negative number, you flip that over to be positive, and then do a search by index of the components table. Yes, it's hacky and ugly, but it does work. My patches are currently not fit to print right now, but I thought this might be a suitable solution.

Chris, it seems that what you want is bug 38922 (Default CC list for each component), not necessarily this one...

This really depends on having ids for compoents/products (bug 38922)

*** Bug 160316 has been marked as a duplicate of this bug. ***

This is the first version of a patch which implements default CC for components (bug 38922), component watching (this bug), an emailprefs table (bug 73665) and many more goodies besides. It's not quite finished - it's been well tested, but there's still some debugging code in there and a short list of issues to be addressed - but we want to get the review process started, so here's the rough cut. Gerv

This patch has a few cleanups; for example, tests now run correctly. There are three known bugs: - The numbers in email.html.tmpl and email.txt.tmpl are hardcoded, as I don't know the syntax for using the constants from BugMail.pm - If the product changes at the same time as the component, component watchers don't get the mail (both old and new component). - On BugMail.pm:469, I needed an odd require Bug; thing to make it work. Gerv

Does this support product watching, eg via component_id IS NULL?

No; you just select all the components in your product. The selection UI, for reasons of non-ambiguity (what do you do if two products have a "General" component?), is a single list of all product/component pairs. The stored value is just the component_id; the product_id doesn't come into it. So having a null component_id could only mean something like "watch everything". Admittedly there is a small problem here; it's not possible to say "watch all components in this product and any new ones that get added." People have to add themselves manually. But I can't see a sensible way of doing this, either in the UI or the underlying implementation. Gerv

When you add a component, see if someone is already watching all the components in that product, and if they are, automatically add them to watching that component as well.

Do we have an ETA on this? We're really hurting without it.

You could do that; but what if they only want to watch the ones they've selected? I guess the first case is more likely than the second, and they could come back and remove themselves from the unwanted component... What if they want everything but one, and have set that up as such? Again, perhaps an edge case. Yeah, we could do that :-) Gerv

Hmm, just applied your patch to a Bugzilla installation, which seems to have stopped sending email since... Is it necessary to apply the patch from bug 73665 as well? Any hints would be more than welcome...

Comment on attachment 139236 [details] [diff] [review] Patch v.2 The patch has bitrotted slightly: >--- Bugzilla/BugMail.pm 22 Nov 2003 03:50:40 -0000 1.8 >+++ Bugzilla/BugMail.pm 17 Jan 2004 00:18:20 -0000 >@@ -25,33 +25,76 @@ [...] > use Bugzilla::Config qw(:DEFAULT $datadir); >+use Bugzilla::Util; This part is not necessary anymore, that line is already in the latest version of Bugzilla/BugMail.pm. >--- template/en/default/account/prefs/email.html.tmpl 6 Sep 2003 19:23:38 -0000 1.10 >+++ template/en/default/account/prefs/email.html.tmpl 17 Jan 2004 00:18:22 -0000 >@@ -36,43 +36,32 @@ [...] >- [% terms.Bugzilla %] to send mail related to their [% terms.bugs %] to you also. List the should be [%+ terms.Bugzilla %] to send mail related to their [% terms.bugs %] to you also. List the (notice the +)

this would be cool to get in for 2.18... :) This patch is bitrotted though.

Sadly, we're just not there yet on this, if we want 2.18 to happen any time soon. Gerv

I converted patch v.2 to work with the current cvs files. The changes from the previous patch included 1. qualifying references to constants (eg. Bugzilla::BugMail::REL_ANY instead of just REL_ANY) to prevent complaints about bareword references, 2. changed the OPEN sendmail to use sendmail instead of just appending msgs to a file, 3. specified the value order for SQL INSERTs in userprefs.cgi, 4. and using Bugzilla->cgi instead of importing $cgi in userprefs.cgi.

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

Here's a simpler approach that uses inclusions/exclusions lists to specify components to watch and doesn't require any modification of the email preferences or filtering code. This is just the backend. The frontend is also relatively simple, however; indeed, once bug 261181 (which factors out inclusions/exclusions code from flag types into a generic handler for such list) gets checked in, the frontend implementation is trivial.

bug 278455, which is much more general than this bug, would fix the problem. All what you have to do is to look at the component field having the value of the component you want to watch.

Myk, would your patch allow users to configure watching only "new" bugs filed in a component? Or, would it allow users to configure watching only bugs whose summary or comments match a regexp? Thanks

(In reply to comment #50) > Myk, would your patch allow users to configure watching only "new" bugs filed > in a component? Or, would it allow users to configure watching only bugs whose > summary or comments match a regexp? Sorry, no, it would not allow users to configure either of those things.

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

*** Bug 335510 has been marked as a duplicate of this bug. ***

*** Bug 352491 has been marked as a duplicate of this bug. ***

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

If someone were to ask me, which they wisely won't, or I had the time to spend a weekend implementing it, which I sadly don't, this is what I'd do to get the 90% case of component/product-watching working: 1) when a bug is changed, process watchlists for <product>-watch@__internal__ and <product>-<component>-watch@__internal__ for both incoming and outgoing product and component settings, in the qa-contact capacity (or another capacity that's added for this purpose, if one were feeling fancy) 2) add a tiny bit of UI for people to check/uncheck the products and components they want to watch, which would add/remove those addresses from their watchlist 3) filter @__internal__ addresses out of other such lists and and checks You don't get exclusions, though you can manually simulate them. You do get product watching as well as component watching. You do get something that doesn't require schema changes and can likely be made to work in a weekend, since the changes are pretty localized (and don't even need the tiny bit of UI to be useful to a _lot_ of people at first). I hope that's helpful to someone.

If this happens in 3.2, it will be as bug 278455.

I'm no longer working on this. Gerv

FWIW, shaver was wrong in assuming that we don't use foreign keys. I'm going to see if I can put together a version which just creates all of the magical anonymous components (and maybe platforms). I'll probably use: {name}-{type}-watch@__internal__ to allow for classification|product|component|hardware|platform

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

FYI, glob implemented this as an extension for bmo. Maybe he could contribute back?

(In reply to comment #61) > FYI, glob implemented this as an extension for bmo. Maybe he could > contribute back? Cool! Would be possible to extend it for other fields as well? Like version, milestones, etc?

(In reply to comment #61) > FYI, glob implemented this as an extension for bmo. Maybe he could > contribute back? the extension i wrote for bmo doesn't cover all the requirements listed on this bug. i'm happy to bring it upstream in its current form, however i don't have the time or inclination to modify it to suit the requirements stated here. (In reply to comment #62) > Cool! Would be possible to extend it for other fields as well? Like version, > milestones, etc? that's bug 278455.

(In reply to Max Kanat-Alexander from comment #57) > If this happens in 3.2, it will be as bug 278455. Wouldn't this qualify as DUPLICATE then?

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

What does Bugzilla.mozilla.org use, because I see Component Watching there. https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch

B.M.O uses an extension called ComponentWatching: http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/ComponentWatching/

bmo's implementation of component watching, which just uses inclusions, works well and should be brought upstream as is. additional functionality, such as exclusions, can be added later in other bugs.

Dropping priority to reflect reality, but it is still on a to-do list.