Duplicate email sends link to +subscribe

I agree; if you're already subscribed to the master bug, a subscribe
link is pointless - include a link to the bug rather than a
subscription offer.

Note that for most people, they are subscribed to the master *via* the
duplicate, so perhaps noone needs the subscribe link?

As for what the subscription offer should /show/ - thats an
interesting, different question to me - it could show the bug with a
tasteful 'subscribe?' prompt, when you land without a referrer.

Hi, guys. I get the request here but in the context of the other bug, John suggests something has been broken. Did we actually break something around a link that used to be in bug mail? Or are the ideas outlined in this request the main issue?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/9/2010 3:38 PM, Deryck Hodge wrote:
> Hi, guys. I get the request here but in the context of the other bug,
> John suggests something has been broken. Did we actually break
> something around a link that used to be in bug mail? Or are the ideas
> outlined in this request the main issue?
>

I dug through some old emails. This is what you used to send:
> *** This bug is a duplicate of bug 322807 ***
> https://bugs.launchpad.net/bugs/322807
>
> ** This bug has been marked a duplicate of bug 322807
> Adding files on Windows fails because first character is ignored

This is the content of the new bug email:
> The second traceback is bug 501166 and why
> lp:~gz/bzr/require_testtools_0.9.5_for_selftestand the rt to get
> testtools upgraded on PQM exist.
>
> ** This bug has been marked a duplicate of bug 501166
> testtools should be able to cope with non-ascii tracebacks
> * You can subscribe to bug 501166 by following this link: https://bugs.launchpad.net/testtools/+bug/501166/+subscribe
>
> ** This bug is no longer a duplicate of bug 501166
> testtools should be able to cope with non-ascii tracebacks

Aside from the "marked as duplicate, no longer a duplicate", You can see
that the bug link changed from:
  https://bugs.launchpad.net/bugs/?????
to
  * You can subscribe to bug ???? by following this link:
     https://bugs.launchpad.net/bugs/????/+subscribe

So you removed the (useful to me) direct link to the bug, and added a
(not useful to me) direct link to subscribe.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzZ/MsACgkQJdeBCYSNAANE0QCeKnkWhIpLmQs0d4QkjVXVXwtF
lfMAn3w2bgYGaqjmfK+WYmG18r3daJnK
=rIGp
-----END PGP SIGNATURE-----

Gotcha. Makes sense now. Thanks, John.

After talking with Graham on IRC, we have some cleanup to do around the change that led to this bug.

We need to:

 * Be sure if we're sending email notifications to subscribers via duplicates or not
 * Make sure the web UI reflects this state accurately (i.e. don't display the user if he/she isn't getting mail)
 * Make sure we have a direct link to the master bug first
 * Then a notice if the user is not subscribed and a link pointing to where he/she can subscribe

Something that's confusing me as I look at the code and at recent notifications is this block lp.bugs.scripts.bugnotification.py:

    if bug.duplicateof is not None:
        text_notifications.append(
            '*** This bug is a duplicate of bug %d ***\n %s' %
                (bug.duplicateof.id, canonical_url(bug.duplicateof)))

This happens before the notification is constructed. Looking back at a recent notification on a duplicate bug, I can see that the notification starts thus:

> *** This bug is a duplicate of bug 655385 ***
> https://bugs.launchpad.net/bugs/655385

John, wouldn't that fulfill your use-case of having a direct link to the master bug?

On 10 November 2010 15:06, Deryck Hodge <email address hidden> wrote:
>  * Be sure if we're sending email notifications to subscribers via duplicates or not

We are *not* sending notifications about the master bug to dupe
subscribers. Line 1017 of lp.bugs.model.bug is the conditional for
this and the first part of that conditional defaults to False.

>  * Make sure the web UI reflects this state accurately (i.e. don't display the user if he/she isn't getting mail)

So, should we drop the subscribers-via-duplicates list from the
subscribers portlet? I can't remember what we said when we talked
about this the other day (and that should be a separate bug).

>  * Make sure we have a direct link to the master bug first

See my previous response. I think we already have this.

>  * Then a notice if the user is not subscribed and a link pointing to where he/she can subscribe

Again, if I'm right above, this is the situation as it currently stands.

Moving this to incomplete since I'm not sure what the current situation is with this bug.

On Sun, 2010-11-14 at 15:00 +0000, Graham Binns wrote:
> On 10 November 2010 15:06, Deryck Hodge <email address hidden> wrote:
> > * Be sure if we're sending email notifications to subscribers via duplicates or not
>
> We are *not* sending notifications about the master bug to dupe
> subscribers. Line 1017 of lp.bugs.model.bug is the conditional for
> this and the first part of that conditional defaults to False.

Actually dupe subscribers are notified about the master bug. In fact I'm
subscribed to bug #674815 and I'm receiving all the comments and status
changes that are being made on this bug.

And just for this reason I think Launchpad shouldn't send links to
+subscribe.

On 14 November 2010 15:18, Andrea Corbellini
<email address hidden> wrote:
>> We are *not* sending notifications about the master bug to dupe
>> subscribers. Line 1017 of lp.bugs.model.bug is the conditional for
>> this and the first part of that conditional defaults to False.
>
> Actually dupe subscribers are notified about the master bug. In fact I'm
> subscribed to bug #674815 and I'm receiving all the comments and status
> changes that are being made on this bug.
>
> And just for this reason I think Launchpad shouldn't send links to
> +subscribe.
>

Okay, that's just plain weird. I shall investigate further. Thanks for
letting me know.

On 14 November 2010 15:27, Graham Binns <email address hidden> wrote:
>> Actually dupe subscribers are notified about the master bug. In fact I'm
>> subscribed to bug #674815 and I'm receiving all the comments and status
>> changes that are being made on this bug.
>

So, ignore my previous comment about us not sending these. The code I
read (wrongly) is for sending notifications about changes to
duplicates to the subscriber of the master bug. Which we don't do.
Which is fine.

Andrea is quite right; we *do* send notifications about the master bug
to subscribers of its duplicates.

Showing:

> *** This bug is a duplicate of bug 655385 ***
> https://bugs.launchpad.net/bugs/655385

Is what we used to show, and stopped showing. If we just bring it back, that works for me.

John, that is still sent when the bug is marked as a duplicate. In the email that you quoted, the bug was marked then quickly unmarked, so it was not a duplicate at the time the notification was sent.

On 15 November 2010 04:11, William Grant <email address hidden> wrote:
> John, that is still sent when the bug is marked as a duplicate. In the
> email that you quoted, the bug was marked then quickly unmarked, so it
> was not a duplicate at the time the notification was sent.
>

That's another good case for bug 164196, then: "Quickly-undone actions
shouldn't send mail notifications." (And thanks for spotting that,
William. I appear to have suffered a reading-of-things deficiency
whilst I've been looking at this bug).

I'm marking this invalid since it's not a bug, but in fact confusion caused by a manifestation of bug 164196.

Hi,

In bug #674815 (duplicate of this one) I'm describing other problems
caused by the fact that +subscribe links are sent. So I think that
either my bug shouldn't be considered a duplicate or this bug shouldn't
be invalid.

On Mon, 2010-11-15 at 14:05 +0000, Graham Binns wrote:
> I'm marking this invalid since it's not a bug, but in fact confusion
> caused by a manifestation of bug 164196.
>
> ** Changed in: malone
> Status: In Progress => Invalid