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 17:10:34 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhortuneAccountViewController extends PhortuneController {
|
|
|
|
|
|
|
|
private $accountID;
|
|
|
|
|
|
|
|
public function willProcessRequest(array $data) {
|
|
|
|
$this->accountID = $data['accountID'];
|
|
|
|
}
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$user = $request->getUser();
|
|
|
|
|
2014-10-09 00:33:25 +02:00
|
|
|
// TODO: Currently, you must be able to edit an account to view the detail
|
|
|
|
// page, because the account must be broadly visible so merchants can
|
|
|
|
// process orders but merchants should not be able to see all the details
|
|
|
|
// of an account. Ideally this page should be visible to merchants, too,
|
|
|
|
// just with less information.
|
|
|
|
|
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 17:10:34 +01:00
|
|
|
$account = id(new PhortuneAccountQuery())
|
|
|
|
->setViewer($user)
|
|
|
|
->withIDs(array($this->accountID))
|
2014-10-09 00:33:25 +02:00
|
|
|
->requireCapabilities(
|
|
|
|
array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
))
|
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 17:10:34 +01:00
|
|
|
->executeOne();
|
|
|
|
|
|
|
|
if (!$account) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
|
|
|
$title = $account->getName();
|
|
|
|
|
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
2013-12-19 02:47:34 +01:00
|
|
|
$crumbs->addTextCrumb(pht('Account'), $request->getRequestURI());
|
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 17:10:34 +01:00
|
|
|
|
2013-09-17 18:12:37 +02:00
|
|
|
$header = id(new PHUIHeaderView())
|
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 17:10:34 +01:00
|
|
|
->setHeader($title);
|
|
|
|
|
|
|
|
$actions = id(new PhabricatorActionListView())
|
|
|
|
->setUser($user)
|
2013-07-12 20:39:47 +02:00
|
|
|
->setObjectURI($request->getRequestURI())
|
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 17:10:34 +01:00
|
|
|
->addAction(
|
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Edit Account'))
|
2014-05-12 19:08:32 +02:00
|
|
|
->setIcon('fa-pencil')
|
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 17:10:34 +01:00
|
|
|
->setHref('#')
|
|
|
|
->setDisabled(true))
|
|
|
|
->addAction(
|
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Edit Members'))
|
2014-05-12 19:08:32 +02:00
|
|
|
->setIcon('fa-users')
|
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 17:10:34 +01:00
|
|
|
->setHref('#')
|
|
|
|
->setDisabled(true));
|
|
|
|
|
2013-04-10 22:08:36 +02:00
|
|
|
$crumbs->setActionList($actions);
|
|
|
|
|
2013-10-11 16:53:56 +02:00
|
|
|
$properties = id(new PHUIPropertyListView())
|
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 17:10:34 +01:00
|
|
|
->setObject($account)
|
|
|
|
->setUser($user);
|
|
|
|
|
2013-10-11 16:53:56 +02:00
|
|
|
$properties->setActionList($actions);
|
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 17:10:34 +01:00
|
|
|
|
|
|
|
$payment_methods = $this->buildPaymentMethodsSection($account);
|
2013-03-28 17:13:07 +01:00
|
|
|
$purchase_history = $this->buildPurchaseHistorySection($account);
|
2014-07-23 19:36:12 +02:00
|
|
|
$charge_history = $this->buildChargeHistorySection($account);
|
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 17:10:34 +01:00
|
|
|
$account_history = $this->buildAccountHistorySection($account);
|
|
|
|
|
2013-09-29 00:55:38 +02:00
|
|
|
$object_box = id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
2013-10-11 16:53:56 +02:00
|
|
|
->addPropertyList($properties);
|
2013-09-29 00:55:38 +02: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 17:10:34 +01:00
|
|
|
return $this->buildApplicationPage(
|
|
|
|
array(
|
|
|
|
$crumbs,
|
2013-09-29 00:55:38 +02:00
|
|
|
$object_box,
|
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 17:10:34 +01:00
|
|
|
$payment_methods,
|
2013-03-28 17:13:07 +01:00
|
|
|
$purchase_history,
|
2014-07-23 19:36:12 +02:00
|
|
|
$charge_history,
|
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 17:10:34 +01:00
|
|
|
$account_history,
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'title' => $title,
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildPaymentMethodsSection(PhortuneAccount $account) {
|
|
|
|
$request = $this->getRequest();
|
2014-08-11 21:07:35 +02:00
|
|
|
$viewer = $request->getUser();
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$account,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
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 17:10:34 +01:00
|
|
|
|
|
|
|
$id = $account->getID();
|
|
|
|
|
2014-07-13 18:18:50 +02:00
|
|
|
$header = id(new PHUIHeaderView())
|
2014-10-07 23:41:59 +02:00
|
|
|
->setHeader(pht('Payment Methods'));
|
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 17:10:34 +01:00
|
|
|
|
2013-09-09 23:14:34 +02:00
|
|
|
$list = id(new PHUIObjectItemListView())
|
2014-08-11 21:07:35 +02:00
|
|
|
->setUser($viewer)
|
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 17:10:34 +01:00
|
|
|
->setNoDataString(
|
|
|
|
pht('No payment methods associated with this account.'));
|
|
|
|
|
2013-03-28 17:11:42 +01:00
|
|
|
$methods = id(new PhortunePaymentMethodQuery())
|
2014-08-11 21:07:35 +02:00
|
|
|
->setViewer($viewer)
|
2013-03-28 17:11:42 +01:00
|
|
|
->withAccountPHIDs(array($account->getPHID()))
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
if ($methods) {
|
|
|
|
$this->loadHandles(mpull($methods, 'getAuthorPHID'));
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($methods as $method) {
|
2014-08-11 21:07:35 +02:00
|
|
|
$id = $method->getID();
|
|
|
|
|
2013-09-09 23:14:34 +02:00
|
|
|
$item = new PHUIObjectItemView();
|
2014-08-11 21:07:35 +02:00
|
|
|
$item->setHeader($method->getFullDisplayName());
|
2013-03-28 17:11:42 +01:00
|
|
|
|
|
|
|
switch ($method->getStatus()) {
|
|
|
|
case PhortunePaymentMethod::STATUS_ACTIVE:
|
|
|
|
$item->setBarColor('green');
|
2014-08-11 21:07:35 +02:00
|
|
|
|
|
|
|
$disable_uri = $this->getApplicationURI('card/'.$id.'/disable/');
|
|
|
|
$item->addAction(
|
|
|
|
id(new PHUIListItemView())
|
|
|
|
->setIcon('fa-times')
|
|
|
|
->setHref($disable_uri)
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(true));
|
|
|
|
break;
|
|
|
|
case PhortunePaymentMethod::STATUS_DISABLED:
|
|
|
|
$item->setDisabled(true);
|
2013-03-28 17:11:42 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2014-08-11 21:07:35 +02:00
|
|
|
$provider = $method->buildPaymentProvider();
|
|
|
|
$item->addAttribute($provider->getPaymentMethodProviderDescription());
|
|
|
|
|
|
|
|
$edit_uri = $this->getApplicationURI('card/'.$id.'/edit/');
|
|
|
|
|
|
|
|
$item->addAction(
|
|
|
|
id(new PHUIListItemView())
|
|
|
|
->setIcon('fa-pencil')
|
|
|
|
->setHref($edit_uri)
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit));
|
2013-03-28 17:11:42 +01:00
|
|
|
|
|
|
|
$list->addItem($item);
|
|
|
|
}
|
|
|
|
|
2014-07-13 18:18:50 +02:00
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
|
|
|
->appendChild($list);
|
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 17:10:34 +01:00
|
|
|
}
|
|
|
|
|
2013-03-28 17:13:07 +01:00
|
|
|
private function buildPurchaseHistorySection(PhortuneAccount $account) {
|
|
|
|
$request = $this->getRequest();
|
2014-08-11 21:10:09 +02:00
|
|
|
$viewer = $request->getUser();
|
|
|
|
|
|
|
|
$carts = id(new PhortuneCartQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withAccountPHIDs(array($account->getPHID()))
|
|
|
|
->needPurchases(true)
|
|
|
|
->withStatuses(
|
|
|
|
array(
|
|
|
|
PhortuneCart::STATUS_PURCHASING,
|
2014-10-10 01:57:52 +02:00
|
|
|
PhortuneCart::STATUS_CHARGED,
|
|
|
|
PhortuneCart::STATUS_HOLD,
|
2014-08-11 21:10:09 +02:00
|
|
|
PhortuneCart::STATUS_PURCHASED,
|
|
|
|
))
|
|
|
|
->execute();
|
|
|
|
|
2014-10-08 14:32:01 +02:00
|
|
|
$phids = array();
|
|
|
|
foreach ($carts as $cart) {
|
|
|
|
$phids[] = $cart->getPHID();
|
|
|
|
foreach ($cart->getPurchases() as $purchase) {
|
|
|
|
$phids[] = $purchase->getPHID();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
$handles = $this->loadViewerHandles($phids);
|
|
|
|
|
2014-08-11 21:10:09 +02:00
|
|
|
$rows = array();
|
|
|
|
$rowc = array();
|
|
|
|
foreach ($carts as $cart) {
|
2014-10-08 14:32:01 +02:00
|
|
|
$cart_link = $handles[$cart->getPHID()]->renderLink();
|
|
|
|
$purchases = $cart->getPurchases();
|
|
|
|
|
|
|
|
if (count($purchases) == 1) {
|
|
|
|
$purchase_name = $handles[$purchase->getPHID()]->renderLink();
|
|
|
|
$purchases = array();
|
|
|
|
} else {
|
|
|
|
$purchase_name = '';
|
|
|
|
}
|
2014-08-18 22:15:21 +02:00
|
|
|
|
2014-10-08 14:32:01 +02:00
|
|
|
$rowc[] = '';
|
2014-08-11 21:10:09 +02:00
|
|
|
$rows[] = array(
|
2014-10-10 01:57:52 +02:00
|
|
|
$cart->getID(),
|
2014-10-08 14:32:01 +02:00
|
|
|
phutil_tag(
|
|
|
|
'strong',
|
|
|
|
array(),
|
|
|
|
$cart_link),
|
|
|
|
$purchase_name,
|
|
|
|
phutil_tag(
|
|
|
|
'strong',
|
|
|
|
array(),
|
|
|
|
$cart->getTotalPriceAsCurrency()->formatForDisplay()),
|
2014-10-10 01:57:52 +02:00
|
|
|
PhortuneCart::getNameForStatus($cart->getStatus()),
|
2014-10-08 14:32:01 +02:00
|
|
|
phabricator_datetime($cart->getDateModified(), $viewer),
|
2014-08-11 21:10:09 +02:00
|
|
|
);
|
2014-10-08 14:32:01 +02:00
|
|
|
foreach ($purchases as $purchase) {
|
2014-08-18 22:15:21 +02:00
|
|
|
$id = $purchase->getID();
|
|
|
|
|
2014-10-06 19:26:48 +02:00
|
|
|
$price = $purchase->getTotalPriceAsCurrency()->formatForDisplay();
|
2014-08-11 21:10:09 +02:00
|
|
|
|
|
|
|
$rowc[] = '';
|
|
|
|
$rows[] = array(
|
|
|
|
'',
|
2014-10-08 14:32:01 +02:00
|
|
|
$handles[$purchase->getPHID()]->renderLink(),
|
2014-08-11 21:10:09 +02:00
|
|
|
$price,
|
2014-10-08 14:32:01 +02:00
|
|
|
'',
|
2014-10-10 01:57:52 +02:00
|
|
|
'',
|
2014-08-11 21:10:09 +02:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$table = id(new AphrontTableView($rows))
|
|
|
|
->setRowClasses($rowc)
|
|
|
|
->setHeaders(
|
|
|
|
array(
|
2014-10-10 01:57:52 +02:00
|
|
|
pht('ID'),
|
|
|
|
pht('Order'),
|
2014-08-11 21:10:09 +02:00
|
|
|
pht('Purchase'),
|
|
|
|
pht('Amount'),
|
2014-10-10 01:57:52 +02:00
|
|
|
pht('Status'),
|
2014-10-08 14:32:01 +02:00
|
|
|
pht('Updated'),
|
2014-08-11 21:10:09 +02:00
|
|
|
))
|
|
|
|
->setColumnClasses(
|
|
|
|
array(
|
2014-10-10 01:57:52 +02:00
|
|
|
'',
|
2014-08-11 21:10:09 +02:00
|
|
|
'',
|
|
|
|
'wide',
|
|
|
|
'right',
|
2014-10-10 01:57:52 +02:00
|
|
|
'',
|
2014-10-08 14:32:01 +02:00
|
|
|
'right',
|
2014-08-11 21:10:09 +02:00
|
|
|
));
|
2013-03-28 17:13:07 +01:00
|
|
|
|
2013-09-17 18:12:37 +02:00
|
|
|
$header = id(new PHUIHeaderView())
|
2014-10-10 01:57:52 +02:00
|
|
|
->setHeader(pht('Order History'));
|
2013-03-28 17:13:07 +01:00
|
|
|
|
2014-07-13 18:18:50 +02:00
|
|
|
return id(new PHUIObjectBoxView())
|
2014-08-11 21:10:09 +02:00
|
|
|
->setHeader($header)
|
|
|
|
->appendChild($table);
|
2013-03-28 17:13:07 +01:00
|
|
|
}
|
|
|
|
|
2014-07-23 19:36:12 +02:00
|
|
|
private function buildChargeHistorySection(PhortuneAccount $account) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$viewer = $request->getUser();
|
|
|
|
|
|
|
|
$charges = id(new PhortuneChargeQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withAccountPHIDs(array($account->getPHID()))
|
2014-08-18 22:15:21 +02:00
|
|
|
->needCarts(true)
|
2014-07-23 19:36:12 +02:00
|
|
|
->execute();
|
|
|
|
|
2014-07-23 19:36:25 +02:00
|
|
|
return $this->buildChargesTable($charges);
|
2014-07-23 19:36:12 +02: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 17:10:34 +01:00
|
|
|
private function buildAccountHistorySection(PhortuneAccount $account) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$user = $request->getUser();
|
|
|
|
|
|
|
|
$xactions = id(new PhortuneAccountTransactionQuery())
|
|
|
|
->setViewer($user)
|
|
|
|
->withObjectPHIDs(array($account->getPHID()))
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
$engine = id(new PhabricatorMarkupEngine())
|
|
|
|
->setViewer($user);
|
|
|
|
|
|
|
|
$xaction_view = id(new PhabricatorApplicationTransactionView())
|
|
|
|
->setUser($user)
|
2013-07-29 03:21:22 +02:00
|
|
|
->setObjectPHID($account->getPHID())
|
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 17:10:34 +01:00
|
|
|
->setTransactions($xactions)
|
|
|
|
->setMarkupEngine($engine);
|
|
|
|
|
2014-10-08 14:32:01 +02:00
|
|
|
return $xaction_view;
|
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 17:10:34 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|