Email Verification

[clone1018]

We need email verification with Gittip. This Issue and associated PR's will need to handle:

• Add initial mandrill support & keys (how to test?) Add Mandrill #2313
• Sending emails to all accounts on initial merge.
• Send verification email on email add/change
• Add new page for verifying email.
• Somehow test everything above (pls help)

The $110 bounty on this issue has been claimed at Bountysource.

[clone1018]

I'm redocumenting a couple of things here to keep my on track for the various PR's.

• Wrapper function for all email, gittip.utils.mail(**kw). Same syntax as Mandrill's messages.send
• We'll want HTML emails to be first class for proper formatting of receipts and links. We'll need to include a pure-text version of each?
• add_event on every individual participant email, add_event on a single mass email.
• Ideal participant mail syntax will be:

whit = Participant.from_id('whit537')
whit.mail(**kw)

• Emails should come from no-reply, notifications or [email protected] and the reply-to should be [email protected]
• Email templates should be contained in templates/email/

[chadwhitacre]

Same syntax as Mandrill's messages.send.

This is different than what I understood. IRC

[chadwhitacre]

Actually? I think this would be a good place to write a standalone library that www.gittip.com uses as a dependency. Along the pattern (most recently) of environment.py.

[chadwhitacre]

The purpose of implementing as a standalone library is to force ourselves to properly design, document, and test the API we want here.

[chadwhitacre]

Here are the five libraries we already have implemented as I'm proposing:

• algorithm.py
• dependency_injection.py
• environment.py
• filesystem_tree.py
• postgres.py

The repos for these are all under the Gittip org.

[chadwhitacre]

Fwiw, Aspen is on its way to being implemented along the same lines. I want www.gittip.com to move in the same direction.

[chadwhitacre]

I want us to adopt similar disciplines for components we write in other languages (Sass, JavaScript, etc.)

[chadwhitacre]

But I'm getting sort of off topic for this issue, aren't I? :-)

[clone1018]

I'd love to discuss this on a hangout or IRC whenever you have a chance.

[chadwhitacre]

IRC

[chadwhitacre]

I've prioritized this ★★★.

[chadwhitacre]

Dropping back to ★★☆.

[ericmeltzer]

Hi guys. I really want this feature to be built because it's a prerequisite to #2521 which I think is really important. Is there anything I can do as a non-programmer to move it along?

[apetresc]

Is there anything I can do as a non-programmer to move it along?

Bountysource it? :)

[ericmeltzer]

@apetresc Done.

[apetresc]

@ericmeltzer Oh wow, nice :) Well, I've been looking for the right time to jump into Gittip development!

I put together a proposal on the Bountysource, copied here for reference:

I think this project can be broken into 4 phases:

1. @whit537 has expressed a preference for implementing the actual email sending as a standalone library (which interfaces with Mandrill, either explicitly or through a module, to be determined in a ticket). This will be written and tested in a separate repo that I'll transfer ownership of to the gittip org once it's done.

2. Implement the key features/flows that emailing is needed for, as laid out by @clone1018:

   • A verification flow when adding/changing a new email address to an account.
   • (Possibly) asking for an optional email as part of the registration flow, since now it will actually be important to have.

   Other tickets that depend on e-mailing (like backer updates, notifications when a pledged user joins gittip, etc) depend on this ticket, but aren't within its scope.

3. Unit and integration testing for the above.

4. Once everything is working, we'll need to do a one-time verification for all existing e-mail addresses that have already been associated with Gittip accounts. This likely involves a one-time script that we will run when the feature goes live, and designing an email template for it.

My projected timeline for the four phases above are as follows (most of the work is concentrated around weekends because I work on weekdays):
Phase 1 – July 8th
Phase 2 – July 13th
Phase 3 – July 14th
Phase 4 – TBD, since it requires an administrative decision about when to push the feature live, and when to email-blast thousands of people. The script will likely not be much technical work, so it can happen whenever the leadership wants (maybe to coincide with renaming the project to Gratipay?)

Hope this gives a clear idea of my plans for this ticket. It's my first contribution to Gittip :)

[chadwhitacre]

@apetresc Awesome! Thanks for stepping up! In general your plan sounds good. A couple comments:

• Thanks for noticing the standalone library idea. If you get down that path and feel like it's overkill, let me know and we'll discuss.
• I would punt on asking for email during registration flow. Let's look at that after we have verification in place.
• I appreciate the timeline, but I'm not going to put much stock in those date, fwiw. We're an open company. Stuff gets done when it gets done. :-)
• We have 447 emails on file so far.

Okay! Let us know what else you need in order to work on this! :D

[Changaco]

@apetresc Were you able to do any work on this?

[chadwhitacre]

Done in #2752! 💃

[davidak]

can i register using e-mail now?

[Changaco]

@davidak No, the "sign up with email" issue is #1052.