Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class PhortuneController extends PhabricatorController {
|
|
|
|
|
2013-04-25 09:45:07 -07:00
|
|
|
protected function loadActiveAccount(PhabricatorUser $user) {
|
|
|
|
$accounts = id(new PhortuneAccountQuery())
|
|
|
|
->setViewer($user)
|
|
|
|
->withMemberPHIDs(array($user->getPHID()))
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
if (!$accounts) {
|
|
|
|
return $this->createUserAccount($user);
|
|
|
|
} else if (count($accounts) == 1) {
|
|
|
|
return head($accounts);
|
|
|
|
} else {
|
2014-06-09 11:36:49 -07:00
|
|
|
throw new Exception('TODO: No account selection yet.');
|
2013-04-25 09:45:07 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
protected function createUserAccount(PhabricatorUser $user) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
|
|
|
|
$xactions = array();
|
|
|
|
$xactions[] = id(new PhortuneAccountTransaction())
|
|
|
|
->setTransactionType(PhortuneAccountTransaction::TYPE_NAME)
|
|
|
|
->setNewValue(pht('Account (%s)', $user->getUserName()));
|
|
|
|
|
|
|
|
$xactions[] = id(new PhortuneAccountTransaction())
|
|
|
|
->setTransactionType(PhabricatorTransactions::TYPE_EDGE)
|
|
|
|
->setMetadataValue(
|
|
|
|
'edge:type',
|
|
|
|
PhabricatorEdgeConfig::TYPE_ACCOUNT_HAS_MEMBER)
|
|
|
|
->setNewValue(
|
|
|
|
array(
|
|
|
|
'=' => array($user->getPHID() => $user->getPHID()),
|
|
|
|
));
|
|
|
|
|
2013-09-10 14:39:40 -07:00
|
|
|
$account = id(new PhortuneAccount())
|
|
|
|
->attachMemberPHIDs(array());
|
Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
|
|
|
|
$editor = id(new PhortuneAccountEditor())
|
|
|
|
->setActor($user)
|
2013-05-24 10:48:34 -07:00
|
|
|
->setContentSourceFromRequest($request);
|
Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
|
|
|
|
// We create an account for you the first time you visit Phortune.
|
|
|
|
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
|
|
|
|
|
|
|
|
$editor->applyTransactions($account, $xactions);
|
|
|
|
|
|
|
|
unset($unguarded);
|
|
|
|
|
|
|
|
return $account;
|
|
|
|
}
|
|
|
|
|
2014-08-18 13:15:21 -07:00
|
|
|
protected function buildChargesTable(array $charges, $show_cart = true) {
|
2014-07-23 10:36:25 -07:00
|
|
|
$request = $this->getRequest();
|
|
|
|
$viewer = $request->getUser();
|
|
|
|
|
|
|
|
$rows = array();
|
|
|
|
foreach ($charges as $charge) {
|
2014-08-18 13:15:21 -07:00
|
|
|
$cart = $charge->getCart();
|
|
|
|
$cart_id = $cart->getID();
|
|
|
|
$cart_uri = $this->getApplicationURI("cart/{$cart_id}/");
|
|
|
|
$cart_href = phutil_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => $cart_uri,
|
|
|
|
),
|
|
|
|
pht('Cart %d', $cart_id));
|
|
|
|
|
2014-07-23 10:36:25 -07:00
|
|
|
$rows[] = array(
|
|
|
|
$charge->getID(),
|
2014-08-18 13:15:21 -07:00
|
|
|
$cart_href,
|
2014-07-23 10:36:25 -07:00
|
|
|
$charge->getPaymentProviderKey(),
|
|
|
|
$charge->getPaymentMethodPHID(),
|
2014-10-06 10:26:48 -07:00
|
|
|
$charge->getAmountAsCurrency()->formatForDisplay(),
|
2014-07-23 10:36:25 -07:00
|
|
|
$charge->getStatus(),
|
|
|
|
phabricator_datetime($charge->getDateCreated(), $viewer),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
$charge_table = id(new AphrontTableView($rows))
|
|
|
|
->setHeaders(
|
|
|
|
array(
|
2014-08-18 13:15:21 -07:00
|
|
|
pht('ID'),
|
2014-07-23 10:36:25 -07:00
|
|
|
pht('Cart'),
|
|
|
|
pht('Provider'),
|
|
|
|
pht('Method'),
|
|
|
|
pht('Amount'),
|
|
|
|
pht('Status'),
|
|
|
|
pht('Created'),
|
|
|
|
))
|
|
|
|
->setColumnClasses(
|
|
|
|
array(
|
|
|
|
'',
|
2014-08-18 13:15:21 -07:00
|
|
|
'strong',
|
2014-07-23 10:36:25 -07:00
|
|
|
'',
|
|
|
|
'',
|
|
|
|
'wide right',
|
|
|
|
'',
|
|
|
|
'',
|
2014-08-18 13:15:21 -07:00
|
|
|
))
|
|
|
|
->setColumnVisibility(
|
|
|
|
array(
|
|
|
|
true,
|
|
|
|
$show_cart,
|
2014-07-23 10:36:25 -07:00
|
|
|
));
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Charge History'));
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
|
|
|
->appendChild($charge_table);
|
|
|
|
}
|
Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
|
2014-08-18 13:15:21 -07:00
|
|
|
protected function addAccountCrumb(
|
|
|
|
$crumbs,
|
|
|
|
PhortuneAccount $account,
|
|
|
|
$link = true) {
|
|
|
|
|
|
|
|
$name = pht('Account');
|
|
|
|
$href = null;
|
|
|
|
|
|
|
|
if ($link) {
|
|
|
|
$href = $this->getApplicationURI($account->getID().'/');
|
|
|
|
$crumbs->addTextCrumb($name, $href);
|
|
|
|
} else {
|
|
|
|
$crumbs->addTextCrumb($name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Phortune v0
Summary:
Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are:
- **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account.
- **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account.
- **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else.
- **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support.
- **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill.
This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues.
This only implements `Account`, and that only partially.
Test Plan: {F37531}
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2787
Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 09:10:34 -07:00
|
|
|
}
|