Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorAuthInviteController
|
|
|
|
extends PhabricatorAuthController {
|
|
|
|
|
|
|
|
public function shouldRequireLogin() {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
$engine = id(new PhabricatorAuthInviteEngine())
|
|
|
|
->setViewer($viewer);
|
|
|
|
|
|
|
|
if ($request->isFormPost()) {
|
|
|
|
$engine->setUserHasConfirmedVerify(true);
|
|
|
|
}
|
|
|
|
|
2015-02-11 15:06:28 +01:00
|
|
|
$invite_code = $request->getURIData('code');
|
|
|
|
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
try {
|
2015-02-11 15:06:28 +01:00
|
|
|
$invite = $engine->processInviteCode($invite_code);
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
} catch (PhabricatorAuthInviteDialogException $ex) {
|
|
|
|
$response = $this->newDialog()
|
|
|
|
->setTitle($ex->getTitle())
|
|
|
|
->appendParagraph($ex->getBody());
|
|
|
|
|
|
|
|
$submit_text = $ex->getSubmitButtonText();
|
|
|
|
if ($submit_text) {
|
|
|
|
$response->addSubmitButton($submit_text);
|
|
|
|
}
|
|
|
|
|
|
|
|
$submit_uri = $ex->getSubmitButtonURI();
|
|
|
|
if ($submit_uri) {
|
|
|
|
$response->setSubmitURI($submit_uri);
|
|
|
|
}
|
|
|
|
|
|
|
|
$cancel_uri = $ex->getCancelButtonURI();
|
|
|
|
$cancel_text = $ex->getCancelButtonText();
|
|
|
|
if ($cancel_uri && $cancel_text) {
|
|
|
|
$response->addCancelButton($cancel_uri, $cancel_text);
|
|
|
|
} else if ($cancel_uri) {
|
|
|
|
$response->addCancelButton($cancel_uri);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $response;
|
|
|
|
} catch (PhabricatorAuthInviteRegisteredException $ex) {
|
|
|
|
// We're all set on processing this invite, just send the user home.
|
|
|
|
return id(new AphrontRedirectResponse())->setURI('/');
|
|
|
|
}
|
|
|
|
|
2015-02-11 15:06:28 +01:00
|
|
|
// Give the user a cookie with the invite code and send them through
|
|
|
|
// normal registration. We'll adjust the flow there.
|
|
|
|
$request->setCookie(
|
|
|
|
PhabricatorCookies::COOKIE_INVITE,
|
|
|
|
$invite_code);
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
|
2015-02-11 15:06:28 +01:00
|
|
|
return id(new AphrontRedirectResponse())->setURI('/auth/start/');
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
}
|