83245 - Preference to disable e-mail notification of duplicates (dupes)

Status: NEW

(Bugzilla :: Email Notifications, enhancement, P3)

Description

[Stephen Rasku]

I don't really care if another bug is marked duplicate of the one I am
watching.  There should be a preference called "Another bug is marked a
duplicate" (or something like that) which I could disable.

Comment 1

[Jacob Steenhagen]

The filtering prefs do need some refining and I've often thought this would be a
nice addition, but I don't want to add anymore prefs until the backend is
refined in bug 73665.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Mass moving to new product Bugzilla...

Comment 3

[Dave Miller [:justdave]]

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 4

[Dave Miller [:justdave]]

Changing default owner of Email Notifications component to JayPee, a.k.a.
J. Paul Reed ([e-mail]).  Jake will be offline for a few months.

Comment 5

[Dimitrios]

It was for a while that I 've been thinking to file a similar bug report,
thankfully I found this one. No activity since v2.16. I think it's important
because of wasted bandwidth. About 1/4 ~ 1/2 of my daily bugmail is duplication
notifications. I do understand that for some bug owners or reporters it's useful
to be informed: if a bug has duplicates, it's importance is increased. 

But, my impression is that most people (incuding developers) don't like that.
They are overloaded with bugmail, so they simply don't read it or they simply
avoid to cc themselves to any bug. As some well known NS employe said, "it's a
matter of survival". Wouldn't it be nice to make them a little more happy? Mail
filtering is not a perfect solution. Besides, fixing this bug would vastly
reduce bugzilla server bandwidth usage and increase its speed.

Comment 6

[J. Paul Reed [:preed]]

I'm not saying that the backend on this doesn't need some work, but you can't
get what you want by turning off some of the notification in the current email
preferences?

Does turning off "When the bug is resolved/verified" help at all?

A *lot* of email stuff is slated to change for 2.18... trust us, we're working
on it...

Comment 7

[Dave Miller [:justdave]]

JayPee, that'll only handle the bug being marked a duplicate, which you probably
*do* want to get.  The one you don't want is the notification on the original
bug that another bug was marked a duplicate of it.  Because all it is is a
comment on the bug.  So the only way to stop it currently is to ignore comments.
 Bugzilla has a very good infrastruction for handling duplicates now.  The best
course of action is probably to make better use of that infrastructure (the
duplicates table) and make the UI use that infrastructure instead of just adding
comments to the bug...

Comment 8

[Dimitrios]

>The one you don't want is the notification on the original bug that another bug
was marked a duplicate of it.

This is exactly what I wanted to say. Impatiently waiting for 2.18 :-)

Comment 9

[Dimitrios]

Well, I haven't received a single "Bug xxx has been marked as a duplicate of
this bug" bugmail in the last week or so. Particularly very happy for not
receiving such messages from bug 82534 (I used to get at least one per day).
I think we should verify this bug as fixed.

Comment 10

[Dimitrios]

Well, I was wrong. I got 3 bugmails from the aforementioned bug today. I had
"Any field not mentioned above changes" unchecked.

Comment 11

[Michael Lefevre]

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

Comment 12

[Gervase Markham [:gerv]]

This should wait until we have an emailprefs table, IMO - bug 73665.

Gerv

Comment 13

[J. Paul Reed [:preed]]

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

Comment 14

[Michael Lefevre]

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

Comment 15

[Sander]

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

Comment 16

[Jeff Walden [:Waldo]]

I would assume when this is introduced there will be a way to only get duplicate
reports if "real", i.e., user-typed, comments are added?  Blocking all duplicate
reports would eliminate these reports that have extra information, like why the
bug was marked a dup.  I find the extra comments interesting so I'd like to keep
getting them when this gets in.

Comment 17

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 18

[Tobias Sager]

Attachment: mail-duplicates.patch

This is a patch implementing the described functionality. Works for me.
Very small and few changes, couldn't this even go into 2.18?

I appreciate any comments or field tests...

Comment 19

[Vlad Dascalu]

Comment on attachment 158101 [details] [diff] [review]
mail-duplicates.patch

This causes false positives and is a hack.

We need a better infrastructure and after that we can deal with this.

Feel free to provide this, by the way!

Comment 20

[Vlad Dascalu]

Suggested plan:

-> Analyse the current DB schema and see where someone would fit a flag for "X
has been marked as a duplicate of". Introduce the fields in the current schema
if we have no place for it yet. You might want to put a document describing the
new fields (if needed) as attachment and request review on it.
-> Analyse and review things related to the email prefs (like the new email
prefs table) and see how things fit in.
-> Analyse and implement also a solution that would allow for the localization
of the "has been marked a duplicate of" messages.
-> Analyse, review and code checksetup.pl that should populate the DB field
based on the existing comments.
-> Finally, rewrite this patch based on the work above.

Comment 21

[Tobias Sager]

(In reply to comment #20)
> Suggested plan:

I'm sorry, I do not have time to re-engineer bugzilla completely.. (besides,
this is done in different bugs than this here)

My patch simply uses and extends the existing (apparently non localisable) code.
It would introduce new functionality without any new flags/variables and only
minimal code addes/changes based on the same ideas currently doing the stuff.


Bug 73665 will need some more time (as for bug 100089 and blocking bug 84876);
implementing this here would make people happy until those changes get in. I
will love to file a new bug requesting the dep-pref as soon as appropriate,
but this bug imho is a now-issue.
Note this is currently the 7th most voted bug in Bugzilla's bugzilla...

Comment 22

[Dimitrios]

I may state the obvious but the real reason of the concern and so many votes is
bugzilla.mozilla.org. A quick and easy hack (applicable to bugzilla.mozilla.org
only) would save a lot of bandwidth that costs money. As you all know, Mozilla
organization is not backed by AOL anymore.

Comment 23

[Dave Miller [:justdave]]

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 24

[Jeff Walden [:Waldo]]

Speaking as a heavy b.m.o user, this would be very useful for me; I've had about
800 dup notifications in the last year that I'd rather not have gotten.  A fix
would be a huge add for a huge number of users.

The huge blocker bug is fixed, so you're much closer to seeing this implemented
in a non-hackish way.  Chances are just about nil that you'll get this for 2.20,
but I can still dream.  ;-)  Mark this as blocking2.20+ or blocking2.20- as you
think best.

Comment 25

[Myk Melez [:myk] [@mykmelez]]

"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave

Comment 26

[Frédéric Buclin]

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

Comment 27

[Todd Stansell]

Attachment: patch against 2.21 (depends on bug 314269 landing)

I may be getting ahead of myself, but here's a patch against the current tip.  It actually relies on the patch in bug 314269 landing though, so I'm going to next mark this bug as dependent upon that one.  This is because of the checksetup.pl bits to initialize the settings.  Since bug 314269 is the first new email setting, that's where the new block of code in checksetup is coming from.  So, we need that first.  Not to mention the fact that we're incrementing the value of the EVT_* stuff, and I've made this one 10 with bug 314269 (dependency changes) taking 9.  Asking for review from Joel, since he's going to be reviewing the other patch as well.

Todd

Comment 28

[Joel Peshkin]

Comment on attachment 201279 [details] [diff] [review]
patch against 2.21 (depends on bug 314269 landing)


>     elsif ($commentField ne '') {
>-        $events{+EVT_COMMENT} = 1;
>+        # Since being marked as a duplicate is a specific type of comment,
>+        # it's either a DUPLICATE or a COMMENT.  not both.
>+        if ($commentField =~ /has been marked as a duplicate of this bug\. \*\*\*/) {
>+            $events{+EVT_DUPLICATE} = 1;
>+        }
>+        else {
>+            $events{+EVT_COMMENT} = 1;
>+        }

I think this is a bit more error-prone than I would like.

Can you do something to make sure that this is really a duplication rather than a quote of such a message?  Perhaps you can ensure that the ENTIRE comment field is the duplication notation and that 
the bug it refers to has, in fact been marked RESOLVED DUPLICATE of this bug.

Comment 29

[Todd Stansell]

Attachment: v2 - ensure entire comment matches duplicate message

Yeah, I totally agree this needs to be more restrictive.

Are you sure we need to actually verify that the bug the comment refers to is a duplicate in the database?  If the entire comment matches exactly the standard duplicate messages, then it seems that should be sufficient.

Here's a patch that matches either message exactly.  If you *really* think I should verify against the DB, then I can add that, but it seems overkill to me.

Todd

Comment 30

[Frédéric Buclin]

too late for 2.22; the trunk is frozen.

Comment 31

[Vlad Dascalu]

Comment on attachment 201311 [details] [diff] [review]
v2 - ensure entire comment matches duplicate message

Again, like I previously said: anybody can cheat the system implemented by this patch, by typing in the "correct" comment. I won't review+ a system that allows users so easily to generate false positives.

Joel's suggestion of DB-checking looks good! :)

Comment 32

[mmortal03]

(In reply to comment #31)
> (From update of attachment 201311 [details] [diff] [review] [edit])
> Again, like I previously said: anybody can cheat the system implemented by this
> patch, by typing in the "correct" comment. I won't review+ a system that allows
> users so easily to generate false positives.
> 
> Joel's suggestion of DB-checking looks good! :)
> 

Let me see if I follow.  One of the problems here is that someone can enter a comment AND mark a bug a duplicate at the same time, so then the question is, "how do you check to see if that was what happened?"  A further problem is checking whether or not they are quoting a previous comment that set the bug as duplicate, or whether or not they are trying to spoof the duplicate being set. 

I don't know the system very well, but I would assume that these duplicate messages are only sent out when the "Resolution" status actually changes to "Duplicate", right?  So, isn't there a way to check the time when the Resolution status for a bug changed to "Duplcate", and then not send out the corresponding duplcate comment UNLESS it also contains a further comment? 

For the case where someone "spoofs" a duplicate by creating a post containing "*** This bug has been marked as a duplicate of bug # ***", that comment will be sent out to those who are attached to that particular bug, and not to "Bug #", correct?  So that wouldn't even apply here.

Comment 33

[Frédéric Buclin]

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 34

[Frédéric Buclin]

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

Comment 35

[Max Kanat-Alexander]

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 "blocking3.2" tp "?", 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 36

[Frédéric Buclin]

There is no patch to approve.

Comment 37

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Excuse me, I wrong flag.

Comment 38

[Frédéric Buclin]

The code is already frozen to prepare 3.2. We won't take any new enhancement.

Comment 40

[Frédéric Buclin]

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.