Closed Bug 76794 (bz-component-watch) Opened 23 years ago Closed 5 years ago

Implement the ability to watch components

Categories

(Bugzilla :: Email Notifications, enhancement, P3)

Product:
Bugzilla
Component:
Email Notifications
Version:
2.11
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 6.0

People

(Reporter: myk, Assigned: dylanAtHome)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 5 obsolete files)

Patch v.3
84.02 KB, patch
Details | Diff | Splinter Review
alternate patch v1: backend for simpler approach
3.47 KB, patch
Details | Diff | Splinter Review 
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
Status: NEW → ASSIGNED
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.
Assignee: tara → myk
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
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.
Blocks: 14137
Target Milestone: --- → Bugzilla 2.16
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".
Priority: -- → P3
Would be nice if this also supported products (bug #53717).  It seems a little
silly to support one and not the other.
Keywords: patch, review
Component: Bugzilla → Email
Product: Webtools → Bugzilla
Version: Bugzilla 2.11 → 2.11
Attachment #31544 - Attachment is obsolete: true
Attachment #31905 - Attachment is obsolete: true
*** 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.
Depends on: 38922
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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)
Depends on: 43600
*** Bug 160316 has been marked as a duplicate of this bug. ***
Depends on: emailprefs
Attachment #31916 - Flags: review?
Summary: RFE: Implement the ability to watch components → Implement the ability to watch components
Attachment #31916 - Flags: review?
Attached patch Patch v.1 (obsolete) — — Splinter Review 
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
Attachment #31916 - Attachment is obsolete: true
Assignee: myk → gerv
Status: ASSIGNED → NEW
Attached patch Patch v.2 (obsolete) — — Splinter Review 
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
Attachment #139141 - Attachment is obsolete: true
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 +)
Attachment #139236 - Attachment is obsolete: true
this would be cool to get in for 2.18...   :)

This patch is bitrotted though.
Flags: blocking2.18?
Sadly, we're just not there yet on this, if we want 2.18 to happen any time soon.

Gerv
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Attached patch Patch v.3 — — Splinter Review 
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.
Flags: blocking2.18? → blocking2.18-
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
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.
Depends on: bz-field-watch
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.
No longer depends on: 38922, bz-field-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.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
*** Bug 335510 has been marked as a duplicate of this bug. ***
QA Contact: mattyt-bugzilla → default-qa
Keywords: dogfood
Keywords: dogfood
Whiteboard: [wanted-bmo]
*** 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".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
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.
Blocks: 370171
Whiteboard: [wanted-bmo] → [wanted-bmo][roadmap: 3.2]
If this happens in 3.2, it will be as bug 278455.
Whiteboard: [wanted-bmo][roadmap: 3.2] → [wanted-bmo]
I'm no longer working on this.

Gerv
Assignee: gerv → email-notifications
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
Blocks: 95255
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Priority: P3 → P1
Alias: bz-component-watch
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.
See Also: → bz-field-watch
(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.
Target Milestone: Bugzilla 4.4 → ---
What does Bugzilla.mozilla.org use, because I see Component Watching there.

https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch
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.
Assignee: email-notifications → dylan
Whiteboard: [wanted-bmo]
No longer blocks: 95255
Dropping priority to reflect reality, but it is still on a to-do list.
Priority: P1 → P3
Assignee: dylan → dylan

Component Watching is still an extension but will be shipped with Bugzilla 6.0.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Bugzilla 6.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: