People: Accept invite by email subscription only

[roccotripaldi]

closes #668

This PR adds a footer link to the logged out invite accept, allowing an invited user to follow a blog by email subscription only.

To Test

1. Invite a non-wpcom email address to follow your blog
2. log out of wordpress
3. go to /accept-invite/$blog/$inviteKey/$activation_key/$management_key
4. click the link at the bottom reading 'Or follow by email subscription only.'
5. Ensure that you are now following the blog and are redirected to subscribe.wordpress.com

cc: @lezama @ebinnion

[roccotripaldi]

Note: we'll need to add the subscriptionActivationKey to all follower requests. but that can be handled in another PR.

[lezama]

Personally I find it more beautiful ☺️ if we do { acceptInvite, saveSubscriptionActivationKey } instead of importing controller

[lezama]

This is looking good :)

[roccotripaldi]

@lezama thanks for the review. I've address all your feedback. I'm going to look into changing the redirect, and try to do it in this PR.

To clarify, we should redirect to subscribe.wordpress.com/?update=activated&email=$email&key=$key
with YET ANOTHER key.

I think it may be possible to return the latest key on the API after the subscription is activate.

[roccotripaldi]

I changed my mind. In keeping more with the current way we do things, I decided to add the 3rd key to the URL. so now we'll have
/accept-invite/$site/$invite_key/$activation_key/$management_key for follower invites.

All other invites will only have $invite_key

[lezama]

this could be export function acceptInvite(

[roccotripaldi]

@lezama - i did an other iteration taking your feedback into account.

For now, because of API limitations, I'm keeping all 3 keys in the URL

In another PR, we can clean up the URL by perhaps doing something like the signup flow is using,
where it accepts URL GET parameters, adds them to the component, and then makes the URL look pretty by striping out the parameters.

[ebinnion]

Perhaps i'm misunderstand, but an API limitation doesn't necessarily impact whether we do /accept-invite/$site/$invite_key/$activation/$management or /accept-invite/$site/$invite_key?activation=$activation&management=$management. We just need to pass the correct data to the API.

I'm fine with either approach, just wanted to point that out.After re-reading the above comment and realizing that we'll pass three keys, I think I prefer GET parameters and then removing the parameters. If this is functional, we can follow up with that in another PR with a low priority though.

[ebinnion]

My guess is that if we moved to using GET parameters, the heavy lifting would be done here. In this method we would get the GET parameters above (See what I did there 😛 👓 ) and then we would do the page.replace() or similar.

The only other change I think we would need is updating the route in my-sites/invites/index.js to be '/accept-invite/:site_id/:invitation_key.

[ebinnion]

I was wondering if you had changed the endpoint to add the activationKey. But, now I see where you added it 😄

[ebinnion]

Functionally, this seemed to work well. The only issue I noticed is that after clicking the "Follow by email subscription only" link, there was a lag of a second or two before I was redirected without the UI updating.

Perhaps, we could do something similar to #1237 and disable the form once that link is clicked?

[roccotripaldi]

Thanks for the review Eric. I addressed all your feedback.

I was already doing setState( { submitting: true} ); when we clicked the email only link, but the big blue buttons wasn't been disabled. I fixed that here:

https://github.com/Automattic/wp-calypso/pull/1190/files#diff-c1058d9fea1b7d007377a2a1e78a3cccR377

[ebinnion]

The disabling looks good to me!

I am getting a JS error after accepting an invite and then going back to /accept-invite/$invite_key/$activation/$manage.

My guess is that it's related to this block in refreshInvite(). We should probably wrap that in an:

if ( ! error ) {
  // Do work
}