289593 - Tip no longer contains a way to watch UNCONFIRMED bugs

Status: RESOLVED WONTFIX

(Bugzilla :: Email Notifications, defect)

Description

[Max Kanat-Alexander]

A really common thing to do as a QA Contact is to watch bugs only when they are
in the UNCONFIRMED state, or when they are marked as RESOLVED.

We can do this on 2.19.2, but not on the tip.

Comment 1

[Vlad Dascalu]

mkanat: please explain why we could do that on 2.19.2 and why we can no longer
do that on tip. What change caused this? Could you fill the bug in the "depends
on" section? Thank you!

Comment 2

[Max Kanat-Alexander]

Oh, my apologies. :-) Emailprefs changed it so that UNCONFIRMED bugs are
something that you can *except* from the list. Where as before, on 2.19.2,
UNCONFIRMED bugs were just another type of thing that you could watch in the
email preferences table.

Comment 3

[Gervase Markham [:gerv]]

The UI may have made it appear that way, but it wasn't so. From the 2.18 source,
line 633:

        # If the user doesn't want to receive email about unconfirmed
        # bugs, that setting overrides their other preferences, including
        # the preference to receive email when they are added to or removed
        # from a role, so remove them from the list before checking their
        # other preferences.
        if (grep(/Unconfirmed/, @$reasons)
        ...

The unco pref was always a "global override I-dont-care-about-these" pref. The
new UI just makes it more clear.

Gerv

Comment 4

[Max Kanat-Alexander]

Then how in the world is it that I currently get messages on all UNCONFIRMED
bugs in the Bugzilla product whose Default QA is set to "[e-mail]"?

It works quite well.

Comment 5

[Gervase Markham [:gerv]]

Max: I can't tell you why you get certain bugmail without knowing your exact
email configuration, including watching relationships. But the comment and, as
far as I can tell, the code both say that the pref works that way, I've always
understood the pref to work that way, and if I remember the discussion when we
first introduced UNCONFIRMED correctly, the pref was supposed to work that way.
So without more information I'm not considering it a bug that it works that way
now :-)

Gerv

Comment 6

[Max Kanat-Alexander]

The previous logic worked like this:

(0) The default preference is to receive ALL MAIL.
(1) If the user is watching another user, push them into the address stack.
(2) If the user has the "unconfirmed" box UNCHECKED, remove them.

Note that I have the unconfirmed box *checked*. So I am not removed from the
list, and I get mail about the unconfirmed bug.

So yes, indeed it was possible to watch UNCONFIRMED bugs.

Provided that (0) is still true, it's possible that that could still happen.

Comment 7

[Max Kanat-Alexander]

And just to make it more clear, I'm watching "[e-mail]" and
under my "QA Contact" preferences I only have checked:

"When the bug is in the unconfirmed state"
and
"When the bug is resolved or verified"

The whole logic code from before was:

if (grep(/Unconfirmed/, @$reasons)
    && exists($prefs{"email${role}Unconfirmed"})
    && $prefs{"email${role}Unconfirmed"} eq '')

The last line is the one that makes this work, and always has.

Comment 8

[Max Kanat-Alexander]

The code comes from bug 122900, which, although it's titled "allow user to turn
off email notification for Unconfirmed bugs" was intentionally implemented as a
positive preference, because of the way the other preferences were implemented.
So Bugzilla has worked this way for quite some time back into the 2.17 series.

Comment 9

[Gervase Markham [:gerv]]

Max: I don't think I'm quite following you. 

In comment 0 you said "watch bugs only when they are in the UNCONFIRMED state" -
because of the word 'only', I took that to mean that you want bugmail about bugs
which are UNCONFIRMED, but not one which are confirmed.

As I understand it, if you have the boxes:
"When the bug is in the unconfirmed state"
and
"When the bug is resolved or verified"
checked, under the old system, you would get email when *all* bugs (both
confirmed and unconfirmed) are resolved or verified. Am I mistaken? Or did I
misunderstand your "only"?

For clarity, the entire block of code in question is:
+        # If the user doesn't want to receive email about unconfirmed
+        # bugs, that setting overrides their other preferences, including
+        # the preference to receive email when they are added to or removed
+        # from a role, so remove them from the list before checking their
+        # other preferences.
+        if (grep(/Unconfirmed/, @$reasons)
+            && exists($prefs{"email${role}Unconfirmed"})
+            && $prefs{"email${role}Unconfirmed"} eq '')
+        {
+            push(@excludedAddresses, $user);
+            next;
+        }

Note that if the 3-part test passes, the person is *excluded* from getting mail.
So, the UNCO checkbox works as follows:

- checked: first part of test fails, the mainline execution continues, mail (for
both UNCO and confirmed) is filtered according to other prefs

- unchecked and bug is confirmed: third part of test fails, mainline execution
continues etc. as above

- unchecked and bug is UNCO: all parts of test pass, person does not get mail.

So the UNCO boxes then and now work the same - they are global overrides which
allow developers to ignore UNCO bugs, which was why the UNCO state was invented.

Gerv

Comment 10

[Max Kanat-Alexander]

I watch [e-mail].

I have "The bug is in the unconfirmed state" checked.

When a bug is unconfirmed in the Bugzilla product, and anybody makes a change on
it, I get email.

I cannot do that anymore on the tip.

That is all I care about.

If I can somehow still do that on the tip, explain it to me and mark this bug
INVALID.

Comment 11

[Gervase Markham [:gerv]]

> I cannot do that anymore on the tip.

What settings have you tried? I would suggest that you can achieve the same
effect by having the "but not when the bug is in the UNCONFIRMED state" box
_un_checked. If not, please explain how this is different.

Gerv

Comment 12

[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 13

[Jesse Ruderman]

I think the current behavior makes more sense than the old behavior.  See bug
219377.

Comment 14

[Max Kanat-Alexander]

I confirm that this is a problem. I wanted to receive all bugs as long as they were in the UNCONFIRMED state, and I can no longer do that on 2.20. I used to be able to do it on 2.18.

However, instead I now just have a Whine that sends me the bugs that were newly-filed each day, so it's not an issue for me.

Comment 15

[Colin Ogilvie [:cso]]

(In reply to comment #14)
> However, instead I now just have a Whine that sends me the bugs that were
> newly-filed each day, so it's not an issue for me.

Should this really be WONTFIX - some people may still wish this feature, and are not able to use Whines... 

Comment 16

[Max Kanat-Alexander]

(In reply to comment #15)
> (In reply to comment #14)
> > However, instead I now just have a Whine that sends me the bugs that were
> > newly-filed each day, so it's not an issue for me.
> 
> Should this really be WONTFIX - some people may still wish this feature, and
> are not able to use Whines... 

  Yeah, perhaps. I forgot that some people aren't able to use Whines.

  I think a better solution would be to have an emailpref for "When the bug is newly filed." I think there's a bug for that somewhere already, and if there isn't there should be.