Add Opt-Out Support for PostCrashEmail

VERIFIED FIXED in 1.7.5

Status

Socorro
General
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: ozten, Assigned: ozten)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

8 years ago
We need to host an opt-out url and respect this setting when sending PostCrashEmails.

Strawman Design, please discuss:
1) Out going email will have a footer
"To unsubscribe from crash-stats update emails, click http://crash-stats.mozilla.com/user/email/x9234kl234sd98sdfdf3j4".

2) Clicking this link will insert a record into a crash-stats hosted opt out database (table).

3) When sending emails crash-stats will respect the opt-out.

4) There will be no UI for changing your opt-out (after this first release, it can always be built later).
(Assignee)

Updated

8 years ago
Blocks: 588516

Comment 1

8 years ago
This looks reasonable to me.

One thing to keep in mind is that once we send out the "your bug has been fixed" email, we should automatically unsubscribe the user and notify that we did so. That is always going to be the last email for any given report.

As a result, this unsubscribe footer will only apply when we implement the second phase of PostCrash which is about automatically emailing out information as soon as they submit the crash report, or when new SUMO information is available for that particular crash signature.

The actual wording of this signature, will that be part of the actual mail body? If so, we will have the flexibility to customize it more easily in the future. If that's not possible, we should figure out the exact wording of it.
(Assignee)

Comment 2

8 years ago
(In reply to comment #1)

> That is always going to be the last email for any given report

Agreed, but is this an un-subscribe, or just a business rule that we don't email the user more than once for the same issue? It is a feature of the current design, so we don't need opt-out to accomplish this.

> As a result, this unsubscribe footer will only apply when we implement the
> second phase of PostCrash which is about automatically emailing out information
> as soon as they submit the crash report, or when new SUMO information is
> available for that particular crash signature.

What about this case:
User crashes for reason X. We email them that X is fixed. They click unsubscribe. They crash on Y. We fix Y. Should we email them? I would think that complying with anti-spam rules would require us to *not* send an email. Don't we need a way to opt out of all future communication? 

To throw a twist in, they can opt-out of future crashes by removing their email address, but we may already have crash Y in the database, before they opt-out, since there is a lag time between their crashing and us shipping the fix.

Is unsubscribe per specific crash, only for PostCrashEmails, or for all communications from crash-stats.m.c?

> The actual wording of this signature, will that be part of the actual mail
body?

Yes. The email body will allow variables such as UNSUBSCRIBE_URL which would be replaced with the actual url but the rest of the copy is from the author of the email.

Comment 3

8 years ago
sounds like the "unsubscribe me" messages has two contexts.

"don't send me any more information about this crash"  -- as suggested maybe we do this automatically once a message for a signature has been sent.

"don't send these kinds of 'we have fixed your crash' messages to me anymore"
(Assignee)

Comment 4

8 years ago
(In reply to comment #3)

>> don't send me any more information about this crash

Yes, this is a feature of the system. With the current design, it won't let you email the same user for the same issue.
(Assignee)

Comment 5

8 years ago
per a discussion in IRC with laura

Comment #0 is a strawman design, what is the right design for our community? Please add or remove requirements that are the minimal, but the *right* thing to ship with in v1 of this feature.

Comment 6

8 years ago
(In reply to comment #4)
> (In reply to comment #3)
> 
> >> don't send me any more information about this crash
> 
> Yes, this is a feature of the system. With the current design, it won't let you
> email the same user for the same issue.


from the other bug the design is:

  The emails would be limited by the 
    crash signature, 
    product, 
    start date, and end date.

Does this mean we will track the fact that we sent for a single run of start and end date, or for all runs of a given signature?

here is the scenario.

user crashes on day Y that is between day X and day Z
we patch the bug
we notify of bug fix for all crashes between X and Z

user doesn't upgrade
user crashes again on day B between days A and C
we do an update or second pass to notification for recent crashes between A and C

in the second case the user would get a second mail unless we track against all e-mail runs for an given signature.
(Assignee)

Comment 7

8 years ago
Email body will have to variables available:
*|EMAIL_ADDRESS|* - Will be replaced with user's email.
*|UNSUBSCRIBE_URL|* - Will be replaced with user's unique un-subscribe URL.

Example:
If you wish to un-subscribe *|EMAIL_ADDRESS|* from these emails, please go to *|UNSUBSCRIBE_URL|*
Would become:
If you wish to un-subscribe jane@doe@name from these emails, please go to http://crash-stats.mozilla.com/unsubscribe/token/R32lkjSted99w234kljdsf

The format follows Mailchimp's "merge tags" format, which Engagement is already familiar with. Basket doesn't have an analogous feature to copy.

*|UNSUBSCRIBE_URL|* will be required to be used at least once. *|EMAIL_ADDRESS|* will be optional.

These will be documented on the page with the email form.

Updated

8 years ago
Target Milestone: --- → 1.7.4

Updated

8 years ago
Assignee: nobody → ozten.bugs
(Assignee)

Updated

8 years ago
Target Milestone: 1.7.4 → 1.7.5
(Assignee)

Comment 8

8 years ago
Patch is in Bug#588516
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Hey there -- how does QA help you test this?  Thx.
(Assignee)

Comment 10

8 years ago
I'm working on SQL to create test data. I'll add a link to a doc here which you can add to your test plans.
Verified FIXED; Vishal and I tested this [1], and it works.

[1] https://wiki.mozilla.org/QA/Execution/Web_Testing/Socorro/Test_Plan/1.7.5
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: x86 → All
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.