483265 - E-mail template

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Collections, defect, P1)

Description

[Justin Scott [:fligtar]]

Need copy for the e-mail sharing template.

Comment 1

[Justin Scott [:fligtar]]

Subject: {sender's email} recommends {add-on name}

{sender email} wants you to know about the {add-on name} add-on for Mozilla Firefox.

Comments from sender: {optional comment}

Information about {add-on name}:
{add-on summary and link to display page}

---

Add-ons are third party enhancements to Firefox that add new features or modify existing features. You can learn more about add-ons at the <a href="https://addons.mozilla.org">Firefox Add-ons</a> website.

---

Sent by Firefox Add-ons on behalf of {sender email}

Comment 2

[Justin Scott [:fligtar]]

Thoughts on the above email template?

Comment 3

[Justin Scott [:fligtar]]

Fred, can we update the e-mail template with the above please? Also, I'm not sure if this change was already made with the giant API patch, but we should require users to be logged in to send an email.

I think most sharing services send the email from the sender's email address and just add a "Sender" header with the service's name/email.

Comment 4

[Fred Wenzel [:wenzel]]

Would that be on the Bandwagon branch only, as well?

Also, unsure which API patch you are referring to. Do you have a bug number, please?

Comment 5

[Justin Scott [:fligtar]]

Yeah, all the bandwagon development except for the extension is taking place on the bandwagon branch.

And the API megapatch is in bug 478125. Looks like there were in fact some changes to the email stuff in it.

Comment 6

[Fred Wenzel [:wenzel]]

It seems, the recommendation email code is now duplicated (i.e., one API function in the regular API and one in the sharing API). Should I back out the code from the regular API (on trunk and the branch)?

Comment 7

[Fred Wenzel [:wenzel]]

Attachment: Remove recommendation email from regular API

This page is for both the bandwagon branch and trunk, as it removes the recommendation call from the regular API (it is part of the sharing API now and need not be duplicated).

Comment 8

[Fred Wenzel [:wenzel]]

Attachment: Email template patch

This should do it.

Comment 9

[Fred Wenzel [:wenzel]]

Removed sharing from the regular API:
- bandwagon branch: r23732
- trunk: r23733

Comment 10

[Justin Scott [:fligtar]]

Comment on attachment 369165 [details] [diff] [review]
Email template patch

Couple things:
- The "comments from sender" section should only be displayed if the sender actually input comments.

- I'm not sure if SITE_URL will work for this, because the API will be on services.addons.mozilla.org but we want the links to go to addons.mozilla.org.

Comment 11

[Fred Wenzel [:wenzel]]

Attachment: Patch, rev. 2

Good points, should be fixed here.

Comment 12

[Justin Scott [:fligtar]]

Comment on attachment 369177 [details] [diff] [review]
Patch, rev. 2

There's another instance of SITE_URL used, but other than that, looks good!

Comment 13

[Fred Wenzel [:wenzel]]

Committed, minus the second SITE_URL: r23735.

Comment 14

[Justin Scott [:fligtar]]

Just tested it out - very cool.

I noticed that the sender is still "Mozilla Add-ons <[e-mail]>" - most sharing sites I looked at have the email come from the sender's address and have a "Sender" header that would say Mozilla Add-ons <[e-mail]>.

Can we make that change?

Comment 15

[Fred Wenzel [:wenzel]]

Attachment: Sender header patch

Hm, I had to patch the email component for it and read RFC 5322, but now it seems to work well. In my tests it works as expected, showing the user's email as "from" and Mozilla Add-ons as "sender".

Comment 16

[Justin Scott [:fligtar]]

Comment on attachment 369380 [details] [diff] [review]
Sender header patch

Cool, looks good. Thanks!

Comment 17

[Fred Wenzel [:wenzel]]

r23787.

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

Return-Path: <[e-mail]>

<snip>

Reply-To: [e-mail]

<snip>

Sender: "Mozilla Add-ons" <[e-mail]>

Verified FIXED; checked copy, and the above seems right to me, based on comments in this bug.