Last Comment Bug 76794 - (bz-component-watch) Implement the ability to watch components
(bz-component-watch)
: Implement the ability to watch components
Status: NEW
:
Product: Bugzilla
Classification: Server Software
Component: Email Notifications (show other bugs)
: 2.11
: All All
: P3 enhancement with 20 votes (vote)
: ---
Assigned To: Dylan Hardison [:dylan]
: default-qa
:
Mentors:
: 103845 109257 160316 335510 352491 (view as bug list)
Depends on: 43600 emailprefs
Blocks: 370171 14137
  Show dependency treegraph
 
Reported: 2001-04-19 17:25 PDT by Myk Melez [:myk] [@mykmelez]
Modified: 2014-07-17 09:19 PDT (History)
70 users (show)
justdave: blocking2.18-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patches checksetup.pl to create table, userprefs for UI, and processmail for sending mail (13.53 KB, patch)
2001-04-19 17:42 PDT, Myk Melez [:myk] [@mykmelez]
no flags Details | Diff | Splinter Review
non-JS friendly, takes products into account (19.11 KB, patch)
2001-04-23 15:49 PDT, Myk Melez [:myk] [@mykmelez]
no flags Details | Diff | Splinter Review
updated patch w/o a few unnecessary debugging statements (18.98 KB, patch)
2001-04-23 16:24 PDT, Myk Melez [:myk] [@mykmelez]
no flags Details | Diff | Splinter Review
Patch v.1 (82.17 KB, patch)
2004-01-15 12:06 PST, Gervase Markham [:gerv]
no flags Details | Diff | Splinter Review
Patch v.2 (83.19 KB, patch)
2004-01-16 16:21 PST, Gervase Markham [:gerv]
no flags Details | Diff | Splinter Review
Patch v.3 (84.02 KB, patch)
2004-05-04 12:14 PDT, Jon
no flags Details | Diff | Splinter Review
alternate patch v1: backend for simpler approach (3.47 KB, patch)
2004-10-25 20:43 PDT, Myk Melez [:myk] [@mykmelez]
no flags Details | Diff | Splinter Review

Description Myk Melez [:myk] [@mykmelez] 2001-04-19 17:25:47 PDT
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.
Comment 1 Myk Melez [:myk] [@mykmelez] 2001-04-19 17:26:13 PDT
-> myself
Comment 2 Myk Melez [:myk] [@mykmelez] 2001-04-19 17:27:39 PDT
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.
Comment 3 Myk Melez [:myk] [@mykmelez] 2001-04-19 17:29:19 PDT
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.

Comment 4 Myk Melez [:myk] [@mykmelez] 2001-04-19 17:42:19 PDT
Created attachment 31544 [details] [diff] [review]
patches checksetup.pl to create table, userprefs for UI, and processmail for sending mail
Comment 5 Dawn Endico 2001-04-19 19:10:37 PDT
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.
Comment 6 Matthew Tuck [:CodeMachine] 2001-04-19 23:23:31 PDT
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.
Comment 7 Jacob Steenhagen 2001-04-20 05:44:16 PDT
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.
Comment 8 Myk Melez [:myk] [@mykmelez] 2001-04-23 15:49:04 PDT
Created attachment 31905 [details] [diff] [review]
non-JS friendly, takes products into account
Comment 9 Myk Melez [:myk] [@mykmelez] 2001-04-23 16:22:28 PDT
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.


Comment 10 Myk Melez [:myk] [@mykmelez] 2001-04-23 16:24:04 PDT
Created attachment 31916 [details] [diff] [review]
updated patch w/o a few unnecessary debugging statements
Comment 11 Andreas Franke (gone) 2001-04-24 16:48:28 PDT
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?
Comment 12 Matthew Tuck [:CodeMachine] 2001-04-24 18:12:18 PDT
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.
Comment 13 Myk Melez [:myk] [@mykmelez] 2001-04-30 18:29:48 PDT
>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.

Comment 14 Jesse Ruderman 2001-05-01 19:57:56 PDT
See also bug 38922, "[RFE] Wanted: Default CC list for each component".
Comment 15 Matthew Tuck [:CodeMachine] 2001-08-11 08:49:01 PDT
Would be nice if this also supported products (bug #53717).  It seems a little
silly to support one and not the other.
Comment 16 Matthew Tuck [:CodeMachine] 2001-10-13 11:11:52 PDT
*** Bug 103845 has been marked as a duplicate of this bug. ***
Comment 17 Håkan Waara 2001-10-13 11:41:44 PDT
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.
Comment 18 Matthew Tuck [:CodeMachine] 2001-10-18 00:59:24 PDT
Architecturally, this might be waiting on bug #73665.  Or it might be waiting on
product watching.
Comment 19 Aleksey Nogin 2001-10-26 13:00:47 PDT
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.
Comment 20 Håkan Waara 2001-10-26 13:05:22 PDT
Aleksey's suggestions sounds like the ideal way, to me, to fix this!
Comment 21 Christopher Aillon (sabbatical, not receiving bugmail) 2001-11-09 01:34:44 PST
*** Bug 109257 has been marked as a duplicate of this bug. ***
Comment 22 Matthew Tuck [:CodeMachine] 2001-11-09 01:49:07 PST
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.
Comment 23 Aleksey Nogin 2001-11-10 09:41:06 PST
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.
Comment 24 Christopher Aillon (sabbatical, not receiving bugmail) 2001-11-10 10:24:08 PST
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. 
Comment 25 Håkan Waara 2001-11-10 10:52:49 PST
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...
Comment 26 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-10 11:00:19 PST
maybe we need an anti-CC list, which counters the effects of watching on a
per-bug basis...
Comment 27 Matthew Tuck [:CodeMachine] 2001-11-10 11:17:11 PST
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.
Comment 28 Jacob Steenhagen 2001-11-10 11:48:54 PST
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.
Comment 29 Aleksey Nogin 2001-11-10 13:42:33 PST
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...
Comment 30 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-17 18:12:46 PST
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.
Comment 31 Chris Yeh 2001-11-21 10:28:42 PST
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.
Comment 32 Aleksey Nogin 2001-11-21 11:48:56 PST
Chris, it seems that what you want is bug 38922 (Default CC list for each
component), not necessarily this one...
Comment 33 Bradley Baetz (:bbaetz) 2002-07-10 19:22:46 PDT
This really depends on having ids for compoents/products (bug 38922)
Comment 34 Bradley Baetz (:bbaetz) 2002-07-31 16:35:33 PDT
*** Bug 160316 has been marked as a duplicate of this bug. ***
Comment 35 Gervase Markham [:gerv] 2004-01-15 12:06:49 PST
Created attachment 139141 [details] [diff] [review]
Patch v.1

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
Comment 36 Gervase Markham [:gerv] 2004-01-16 16:21:42 PST
Created attachment 139236 [details] [diff] [review]
Patch v.2

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
Comment 37 Matthew Tuck [:CodeMachine] 2004-01-23 20:48:07 PST
Does this support product watching, eg via component_id IS NULL?
Comment 38 Gervase Markham [:gerv] 2004-01-24 00:56:54 PST
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
Comment 39 Hixie (not reading bugmail) 2004-03-07 04:12:15 PST
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.
Comment 40 Hixie (not reading bugmail) 2004-03-07 04:14:00 PST
Do we have an ETA on this? We're really hurting without it.
Comment 41 Gervase Markham [:gerv] 2004-03-07 15:10:10 PST
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
Comment 42 Diego Biurrun 2004-03-09 09:22:10 PST
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 43 Diego Biurrun 2004-03-09 09:28:43 PST
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 +)
Comment 44 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-03-18 02:36:16 PST
this would be cool to get in for 2.18...   :)

This patch is bitrotted though.
Comment 45 Gervase Markham [:gerv] 2004-04-05 14:38:08 PDT
Sadly, we're just not there yet on this, if we want 2.18 to happen any time soon.

Gerv
Comment 46 Jon 2004-05-04 12:14:47 PDT
Created attachment 147644 [details] [diff] [review]
Patch v.3

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.
Comment 47 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-09-18 17:50:43 PDT
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.
Comment 48 Myk Melez [:myk] [@mykmelez] 2004-10-25 20:43:06 PDT
Created attachment 163391 [details] [diff] [review]
alternate patch v1: backend for simpler approach

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.
Comment 49 Frédéric Buclin 2005-06-02 10:07:19 PDT
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.
Comment 50 seth arnold 2005-08-17 16:32:30 PDT
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
Comment 51 Myk Melez [:myk] [@mykmelez] 2005-08-17 17:29:40 PDT
(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.
Comment 52 Frédéric Buclin 2005-11-17 07:20:15 PST
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Comment 53 Frédéric Buclin 2006-04-26 12:34:11 PDT
*** Bug 335510 has been marked as a duplicate of this bug. ***
Comment 54 victory <never@receive.bug.mails.i.hate.spammer> 2006-09-13 02:55:47 PDT
*** Bug 352491 has been marked as a duplicate of this bug. ***
Comment 55 Frédéric Buclin 2006-10-19 12:06:35 PDT
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".
Comment 56 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-12-29 12:41:22 PST
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.
Comment 57 Max Kanat-Alexander 2007-02-27 12:10:34 PST
If this happens in 3.2, it will be as bug 278455.
Comment 58 Gervase Markham [:gerv] 2007-05-25 05:01:57 PDT
I'm no longer working on this.

Gerv
Comment 59 timeless 2007-08-14 01:09:52 PDT
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
Comment 60 Max Kanat-Alexander 2008-02-05 15:16:59 PST
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.
Comment 61 Frédéric Buclin 2011-07-27 05:37:28 PDT
FYI, glob implemented this as an extension for bmo. Maybe he could contribute back?
Comment 62 Tiago Mello [:timello] 2011-07-27 05:43:14 PDT
(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?
Comment 63 Byron Jones ‹:glob› [PTO until 2017-01-09] 2011-07-27 05:56:55 PDT
(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.
Comment 64 miketosh 2011-10-19 12:36:25 PDT
(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?
Comment 65 Frédéric Buclin 2012-08-25 01:59:43 PDT
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.
Comment 66 alanjstr 2013-03-02 07:42:17 PST
What does Bugzilla.mozilla.org use, because I see Component Watching there.

https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch
Comment 67 Tiago Mello [:timello] 2013-03-02 07:57:06 PST
B.M.O uses an extension called ComponentWatching:
http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/ComponentWatching/
Comment 68 Byron Jones ‹:glob› [PTO until 2017-01-09] 2013-12-15 21:37:53 PST
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.
Comment 69 Mark Côté [:mcote] 2014-05-07 07:55:09 PDT
*** Bug 95255 has been marked as a duplicate of this bug. ***
Comment 70 Mark Côté [:mcote] 2014-07-14 11:29:06 PDT
Dropping priority to reflect reality, but it is still on a to-do list.

Note You need to log in before you can comment on or make changes to this bug.